I frequently hear that being a huge reason for Caddy use but looking at the documentation for NGINX [0] and Caddy [1], it doesn't seem to be much different.
[0] https://www.nginx.com/blog/using-free-ssltls-certificates-fr...
Caddy automatically staples and caches OCSP responses by default, as well. OCSP responder outages? No problem. This sometimes brings sites down (esp. Must-Staple certs in Firefox) because other servers' OCSP stapling implementations are not as robust. I remember when gnu.org went down for a while because of this.
Certificate got revoked? No problem, Caddy will automatically detect that via OCSP and replace it for you.
Internal throttling and retry logic makes it more resilient to domain validation problems. Caddy will fall back to a secondary CA if your first CA is having trouble issuing a certificate (i.e. multiple default CAs). Not to mention, when using Let's Encrypt, Caddy will retry with its staging endpoint to help avoid rate limit issues.
Plus, deploy multiple Caddy instances as a cluster and they will automatically share and coordinate management of certificates and OCSP staples. (Doing this is as simple as configuring each Caddy instance to use the same storage backend.)
It's very quick to get started and try out HTTPS: https://caddyserver.com/docs/quick-starts/https
That being said, the rest of the software is not as amazing. Please nginx, could you add automatic HTTPS so I can ditch Caddy?
- The weird license debacle.
- The weird ads in headers debacle.
- I had trouble with advanced usage that should have worked but were not flexible enough, like acting as a cache.
- The marketing rubbed me the wrong way. It was pointing the deficiencies in other established FOSS web servers, basically treating them as relics while Caddy itself had 10% of their features.
Those issues are a thing of the past. There's no use bringing it up again, tbh.
> like acting as a cache
That's fair, we have a WIP cache module here https://github.com/caddyserver/cache-handler, it should be ready soon!
Nope, Caddy is one of a minority that put more than a token effort in, a few others have some optional functionality, that you could choose to use if you know what you're doing, most did nothing, relying on you to roll a Certbot script or whatever to manage the certificates.
I figured corporate products, maybe Microsoft tools, stuff like that, might prefer to provide SCEP or any of the half a dozen mechanisms for certificate issuance that pre-dated ACME (what Let's Encrypt does) but lack the actual proof-of-control mechanism. You can imagine Big Corp decides to have a central ACME service doing DNS proof-of-control and then it uses say SCEP internally to issue the certificates to its own servers. That didn't really happen either.
The situation outside web servers is even worse. SQL Servers, SMTP† and IMAP, IRC, and so on, can't do this as easily as Caddy does, but few of them even made a token effort. I don't have much faith in the "efficient market" hypothesis, but if you're a server admin and you believe in it this ought to really shake you. Apparently you value your own time at zero dollars.
† SMTP is a special case. In principle a CA could (but Let's Encrypt don't) allow you to do proof-of-control via SMTP because it uses one of the ports set aside for proof of control purpose in the Baseline Requirements. So you could imagine a CA offering a new ACME proof-of-control method say smtp-69 that meant suitable mail servers would just get themselves certificates, no extra software. But that is not a thing. Other services like IRC or indeed IMAP are not covered by the BRs and so you could not do this for those servers without a lengthy and political process to amend the BRs first.