3 ms·

I think this focus on the default configuration of Caddy is a poor incentive, in a professional context. Here is the same config for nginx on a Debian box:

I think this focus on the default configuration of Caddy is a poor incentive, in a professional context. Here is the same config for nginx on a Debian box: server { server_name example.com; root /var/www/wordpress; location ~ \.php(/|$) { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php-version-fpm.sock; } ssl_certificate /etc/ssl/local/service.pem; ssl_certificate_key /etc/ssl/local/service-key.pem; } It's very similar to Caddy's, except for the explicit cert. No professional should care about a handful of extra lines. Anyway, in many real life situations, the config will be long and complex, whatever tool you use. In the case above, the cert was created offline with the excellent mkcert from mkcert.dev, which is perfect for a developer machine. In other cases, I've had to use a certificate provided by my client. For the remaining cases, cerbot automates all, including nginx's config. Or if one installs the latest nginx, ACME cert retrieval is now included, so the difference to Caddy is shrinking. I don't deny that Caddy is a worthy tool, but I don't care if it makes me write a few lines less in configuration files that I rarely write or update. Praise should focus on more important features. [edit] The excellent leadership shown in this post seems more important!

christophilus 1y ago
> except for the explicit cert That "except" is doing a lot of lifting, in my opinion. Automatic Let's Encrypt is a big part of why I reach for Caddy. Install, run, done. No cert management headaches. It felt like magic the first time I used it, and now that I think of it, it still does.
- rekoil 1y ago
  Right, in the nginx example above, someone has setup a secondary tool to provide certs at the location referenced, and is also handling renewal of them. Also, if I want to add another domain that should be accepted and reverse proxied to my application, in Caddy I just do this: example.com wp.example.com caddyfreakingrules.example.com { root * /var/www/wordpress php_fastcgi unix//run/php/php-version-fpm.sock file_server } Suddenly not only does my Wordpress site respond on example.com, but also wp.example.com, and caddyfreakingrules.example.com, Caddy will fetch and automatically rotate certs for all three domains, and Caddy will auto-redirect from http to https on all three domains. (Does the ngnix example actually do that?) Another thing, does nginx with the above configuration automatically load new certs if the ones that were there when the process spawned have since expired? Because not only does Caddy automatically renew the certs, it is handled transparently and there's zero downtime (provided nothing changes about the DNS pointers of course). Caddy is freaking awesome! Bonus, if this were your Caddyfile (the entire thing, this is all that's needed!): { admin off auto_https prefer_wildcard email hostmaster@example.com cert_issuer acme { dir https://acme-v02.api.letsencrypt.org/directory resolvers 1.1.1.1 1.0.0.1 dns cloudflare {env.CLOUDFLARE_API_TOKEN} } ocsp_stapling off } example.com wp.example.com caddyfreakingrules.example.com { root * /var/www/wordpress php_fastcgi unix//run/php/php-version-fpm.sock file_server } # This is simply to trigger generation of the wildcard cert without # responding with the Wordpress application on all of the domains. *.example.com { respond "This is not the app you're looking for" 404 } Then you'll disable the unauthenticated JSON API on localhost:2019 (which is a good security practice, this is my only gripe with Caddy, this API shouldn't be enabled by default), tell Caddy how to use the DNS-01 ACME resolver against Cloudflare (requires a plugin to Caddy, there are loads for many DNS providers), and then tell Caddy to use appropriate wildcard certs if it has generated them (which for *.example.com it will have). The result of which is that Caddy will only generate one cert for the above 3 sites, and Let's Encrypt won't leak the existance of the wp.example.com and caddyfreakingrules.example.com domains via certificate transparency.
- tacone 1y ago
  I'm under the sensation that nginx most recent release now handles automatic certificates out of the box. That confirms your perception of course.
kstrauser 1y ago
This also has an include directive, so there’s more we’re not seeing. And what’s the SSLLabs score for that setup’s TLS? But it’s not only the config that makes Caddy nice. I think that’s a good example of the kind of care and consideration that goes into Caddy’s development, though.

christophilus 1y ago

> except for the explicit cert That "except" is doing a lot of lifting, in my opinion. Automatic Let's Encrypt is a big part of why I reach for Caddy. Install, run, done. No cert management headaches. It felt like magic the first time I used it, and now that I think of it, it still does.

rekoil 1y ago
Right, in the nginx example above, someone has setup a secondary tool to provide certs at the location referenced, and is also handling renewal of them. Also, if I want to add another domain that should be accepted and reverse proxied to my application, in Caddy I just do this: example.com wp.example.com caddyfreakingrules.example.com { root * /var/www/wordpress php_fastcgi unix//run/php/php-version-fpm.sock file_server } Suddenly not only does my Wordpress site respond on example.com, but also wp.example.com, and caddyfreakingrules.example.com, Caddy will fetch and automatically rotate certs for all three domains, and Caddy will auto-redirect from http to https on all three domains. (Does the ngnix example actually do that?) Another thing, does nginx with the above configuration automatically load new certs if the ones that were there when the process spawned have since expired? Because not only does Caddy automatically renew the certs, it is handled transparently and there's zero downtime (provided nothing changes about the DNS pointers of course). Caddy is freaking awesome! Bonus, if this were your Caddyfile (the entire thing, this is all that's needed!): { admin off auto_https prefer_wildcard email hostmaster@example.com cert_issuer acme { dir https://acme-v02.api.letsencrypt.org/directory resolvers 1.1.1.1 1.0.0.1 dns cloudflare {env.CLOUDFLARE_API_TOKEN} } ocsp_stapling off } example.com wp.example.com caddyfreakingrules.example.com { root * /var/www/wordpress php_fastcgi unix//run/php/php-version-fpm.sock file_server } # This is simply to trigger generation of the wildcard cert without # responding with the Wordpress application on all of the domains. *.example.com { respond "This is not the app you're looking for" 404 } Then you'll disable the unauthenticated JSON API on localhost:2019 (which is a good security practice, this is my only gripe with Caddy, this API shouldn't be enabled by default), tell Caddy how to use the DNS-01 ACME resolver against Cloudflare (requires a plugin to Caddy, there are loads for many DNS providers), and then tell Caddy to use appropriate wildcard certs if it has generated them (which for *.example.com it will have). The result of which is that Caddy will only generate one cert for the above 3 sites, and Let's Encrypt won't leak the existance of the wp.example.com and caddyfreakingrules.example.com domains via certificate transparency.
tacone 1y ago
I'm under the sensation that nginx most recent release now handles automatic certificates out of the box. That confirms your perception of course.

kstrauser 1y ago

This also has an include directive, so there’s more we’re not seeing. And what’s the SSLLabs score for that setup’s TLS? But it’s not only the config that makes Caddy nice. I think that’s a good example of the kind of care and consideration that goes into Caddy’s development, though.