4 ms·
This is really a side-note. I think Caddy is great. > Still the only web server to use TLS automatically and by default. This sounds great at first. It also m
by zimbatm 6y ago
This is really a side-note. I think Caddy is great.
> Still the only web server to use TLS automatically and by default.
This sounds great at first. It also makes it too easy to hit the Let's encrypt rate-limit by mistake and get stuck for a week. I really think that the default should be to use the staging environment certs[1] instead and have the user actively decide when they are ready to go live.
[1]: https://letsencrypt.org/docs/staging-environment/ https://letsencrypt.org/docs/staging-environment/
- francislavoie 6y agoCaddy v2 does this! If an ACME error is encountered, it will continue to retry via the staging endpoint instead until it works. This won't help if you're throwing away the data storage directory though (i.e. not persisting the volume with Docker), because Caddy won't have a way to keep track of what happened in past runs.
- mholt 6y agoWe thought of this! As francislavoie said, Caddy's retry logic involves switching to the Let's Encrypt staging endpoint until the DNS resolves properly. That is coupled with exponential backoff. Hitting the staging endpoint as a test isn't a perfect thing, by the way -- it can help where DNS records are misconfigured, but for things like rate limits or other state internal to the CA server, switching endpoints will only give you a false positive. So, better to not hit that problem in the first place, and to make sure your DNS records are configured properly first. You can read more about these best practices here: https://docs.https.dev/acme-ops#avoid-using-a-production-ca-endpoint-while-testing-or-developing https://docs.https.dev/acme-ops#avoid-using-a-production-ca-...