I’m planning on switching over to Caddy, and have read in a blog post that they spent 5 years developing the automatic SSL technology, along with how advanced it is - but I’m not too sure what that means.
If someone were to use another web server, isn’t it just using Certbot + Let’s Encrypt which handles all the SSL renewals/installations.
What makes Caddy’s SSL feature so advanced compared to the others (i.e. that the 5 years were spent building/refining), could someone please explain.
Thanks!
@matt recently wrote an article for sponsors-only as part of his “Expert Caddy” series called “Automatic HTTPS in Depth”, which explains from top to bottom how the feature works and why it works that way:
https://matt.life/expert-caddy/
In short though, the reasons Caddy’s implementation is superior:
Redundancy – Caddy can have a cert issued from any number of issuers, and by default enables Let’s Encrypt and ZeroSSL; so if one of those go down for whatever reason, the other will pick up the slack. Certbot only defaults to Let’s Encrypt and doesn’t attempt to fallback to any other issuers.
Clustering – you have more than one instance of Caddy, and if they share the same storage, then one instance can start the issuance process and another can solve it, seamlessly. This is not something certbot can do either.
On-Demand TLS – this is a feature exclusive to Caddy, which is possible because the ACME client is tightly integrated with the webserver – Caddy can issue a certificate on the fly if necessary while the client is in the middle of the TLS handshake. Super useful for SaaS businesses who want to allow their users to point their own domains to their service. Plenty of businesses rely on this feature.
Rate limit avoidance – Caddy will exponentially back-off when attempting to issue or renew a cert, and if trying Let’s Encrypt, will fallback to their staging endpoint after the first failure against the production endpoint, to avoid hammering it or counting up the rate limit. Once the staging endpoint works, it’ll revert back to the production endpoint next time it tries. Most certbot setups will just have you run on an hourly cron, which is not ideal and may cause you to hit rate limits.
Those are just some of the points, and most of them are covered already in this page of the docs:
Thanks a lot, really helpful!
I would also add in Caddy’s superior OCSP stapling implementation. It’s by far the best in the industry.
There’s a bunch of little things too that make a big difference. like verifying that storage is properly configured so it can save the certs before trying to get them, the job scheduling, and how it’s optimized to scale well to tens of thousands of certificates. Certbot and frankly most other ACME clients will choke at scale.
This topic was automatically closed after 90 days. New replies are no longer allowed.