I’ve installed Caddy on a couple of Raspberry Pi’s, with a view to secure URLs used for home automation. Each caddy instance serves multiple domains - some plain HTTP, some HTTPS.
While perusing the documentation I noticed the warning to use -ca as argument to Caddy, to avoid rate-limiting by LetsEncrypt. I’ve reviewed their policy at Rate Limits - Let's Encrypt, and found the staging URL described at Staging Environment - Let's Encrypt.
I am now wondering whether:
There is a method to specify the ACME URL in the ‘tls’ section, or only as a command-line arg?
Caddy supports one tls directive per host section? (I’m expecting most hosts to be stable, some to be more volatile)
Caddy is smart enough to batch multiple URLs in the Caddyfile with the same email together into a single certificate with multiple hostnames?
With Caddy 0.9, this became feasible (quite easily, in fact) but is not yet implemented. Yours is the first request; right now only available as a command-line argument. Mainly because there isn’t often a good reason to use different CAs at this point; there are only two CAs (and one of them is fake).
You can use tls multiple times per site as long as the settings do not conflict (if they do, you will either get an error or one will override another). Note that some TLS settings are applied by combining options across multiple sites, because multiple sites are served by the same listener.
Caddy is smart enough not to do this. Automating SAN certificates is more trouble than it’s worth, especially considering the error cases. In automation, we’ve found that single-name certificates are better. Simpler code means less room for error. If we did SAN certificates we’d also have a many-to-many relationship between hostnames and certificates, so we’d have to build indexes – essentially using a database. Then there’s the question of how to handle renewal errors for a certificate with 100 names where 99 succeed but 1 fails to renew. So we just avoid these issues altogether by not using SAN.
OK, don’t fret about a Caddyfile keyword for my sake. My thinking was that stable sites would use the production URL, test sites would use the staging URL.
I’ll have a play with TLS options inside the host-sections then.
From reading the LE rate-limiting page, it appeared to me like they encouraged certificates with multiple names, by virtue of having a different set of (more generous) rate-metrics for that scenario.
Automating SAN certificates is more trouble than it’s worth, especially considering the error cases. In automation, we’ve found that single-name certificates are better. Simpler code means less room for error. If we did SAN certificates we’d also have a many-to-many relationship between hostnames and certificates, so we’d have to build indexes – essentially using a database. Then there’s the question of how to handle renewal errors for a certificate with 100 names where 99 succeed but 1 fails to renew. So we just avoid these issues altogether by not using SAN.