We run Caddy as the TLS termination layer for sigstr.net and *.sigstr.net, with ACME (Let’s Encrypt) via DNS-01 (Route53) and certificate storage in Redis (caddy-storage-redis). We also use (or used) on-demand TLS so arbitrary customer hostnames under our infra can get certificates.
What happened: Large volumes of automated traffic hit the edge with many different hostnames (scans, random subdomains, etc.). That drove many separate Let’s Encrypt certificate issuances for sigstr.net. We then hit Let’s Encrypt’s rate limit (HTTP 429, message like too many certificates (50) already issued for “sigstr.net” in the last 168h0m0s).
After that: Renewal for our main identifiers (sigstr.net, *.sigstr.net) failed while the limit was in effect. In logs we saw “certificate expires soon; queuing for renewal” alongside ACME 429 / rateLimited. Browsers then saw ERR_CERT_DATE_INVALID even though the caddy process was still running.
What we want from Caddy: Guidance on recommended patterns so that on-demand (or similar) issuance cannot exhaust the Let’s Encrypt weekly cap for the registered domain, and on how managed wildcard/apex renewal should behave when shared storage (Redis) and high hostname churn interact—e.g. strict ask policy, disabling on-demand, separate CAs, certificates use other than automatic for wildcards, etc.
OS: Ubuntu (EC2), x86_64
- systemd service: caddy.service
- TLS storage: Redis (module: caddy-storage-redis) for ACME material
- ACME DNS: Route53 plugin for DNS-01