3 ms·

> I switched to Caddy because I just got so sick of the constant pain of certificates. Caddy does certificates automatically That may be fine if you only use t

> I switched to Caddy because I just got so sick of the constant pain of certificates. Caddy does certificates automatically That may be fine if you only use those certificates for port 443 but it falters where certificates are used for the remaining 65533 ports. Instead of leaving certificate request and renewal to individual tools I prefer to centralise it in one spot - a small container or VM is sufficient - which deals out ready-to-run certificates to those systems which need them. When dealt with this way nginx actually has no problems whatsoever with certificates, all it takes is those three (or more depending on your protocol needs) lines in the config file: listen 443 ssl http2; ssl_certificate /etc/letsencrypt/live/site.example.org/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/site.example.org/privkey.pem; The /etc/letsencrypt/live tree gets pushed to the relevant machines by the certificate handling container/VM with certificate files in the form and shape needed by whatever program is to use them. So, in short, the Caddy approach may be fine for those who only run web things but it 'fails' (as in 'adds additional complications') for those who venture beyond port 443.

francislavoie 4y ago
That's not true at all. Caddy can automate certificate issuance with any of the 3 challenge types, either HTTP-01 (requires port 80) TLS-ALPN-01 (requires port 443) or DNS-01 (requires building Caddy with a DNS plugin for your DNS provider). Also you can cluster Caddy by making sure the filesystems are synced, or using a storage module like Redis. Then any of the Caddy instances can do any step of the issuance phase (one can start it, another can complete it). You can use these certificates for sites on non-443 ports as well, once you have the cert. Nothing special at all to do there, you just configure Caddy to serve a site with a different port, e.g. `example.com:65533` You also get numerous other benefits, like OCSP stapling, issuer fallback (if LE is down, it'll try ZeroSSL), etc.
- the_third_wave 4y ago
  You don't seem to understand what I mean when I say 'port 443' - i.e. HTTPS. I'm talking about the use of certificates in non-web applications, e.g. SMTPS, IMAPS, database servers, etc. I prefer not to run a web server on my database servers, mail servers and what have you.

francislavoie 4y ago

That's not true at all. Caddy can automate certificate issuance with any of the 3 challenge types, either HTTP-01 (requires port 80) TLS-ALPN-01 (requires port 443) or DNS-01 (requires building Caddy with a DNS plugin for your DNS provider). Also you can cluster Caddy by making sure the filesystems are synced, or using a storage module like Redis. Then any of the Caddy instances can do any step of the issuance phase (one can start it, another can complete it). You can use these certificates for sites on non-443 ports as well, once you have the cert. Nothing special at all to do there, you just configure Caddy to serve a site with a different port, e.g. `example.com:65533` You also get numerous other benefits, like OCSP stapling, issuer fallback (if LE is down, it'll try ZeroSSL), etc.

the_third_wave 4y ago
You don't seem to understand what I mean when I say 'port 443' - i.e. HTTPS. I'm talking about the use of certificates in non-web applications, e.g. SMTPS, IMAPS, database servers, etc. I prefer not to run a web server on my database servers, mail servers and what have you.