Yeah, my bad, it’s a float64. The default is 1.0 / 3.0 or 0.3333333333333333.
It’s basically the “remaining age of the certificate after which renewal will happen”, so yeah, I guess 0.995 would mean “after 10.8 hours lifetime” (i.e. 90 days * 24 hours * 0.005)
But still. IMO, you’re overcomplicating things here, just delete the older certificates from storage!
when you change the ratio, even if it stops renewing certificates, when someone visits one of the domains that should have been renewed, caddy will try to renew them… so i just got a list and curl-ed from it. I solved it without deleting, i didn’t want to risk any downtime… because it happened many times for the cert to not get generated because of rate limiting
All known issues related to renewing certificates that have been revoked are now fixed on tip. When I first implemented the feature it was more of a party trick, I didn’t have any information that people were really relying on this for anything significant. So I spent a few days and fully implemented it more robustly.
If you want better handling of this situation, I’d recommend building Caddy from the latest commits. We know from production experience that it works.
It wasn’t clear to me until I read the commit message for 2.5, but auto renewing on demand certs does NOT work on 2.4.6.
The early tests I ran seemed to indicate it was working, but on further inspection many of the certs were not getting reissued and failing on some browsers (Safari) but not others (Chrome). Only just starting showing issues today for some reason.
Ended up just taking the nuclear option and deleting all the certs and having new ones created as it was not trivial to build caddy from the latest commits in our workflow.
If anyone else is in this situation, make sure your burst value is high in on_demand_tls - it appears that this value is prorated over the interval. So if you have 100 as the burst value and 1h as the interval then 100 certs won’t get issued straight away - you’ll get 1-2 per min.
Honestly, you probably don’t need to set burst/interval at all, if you properly configured your ask endpoint to only allow whitelisted domains. Caddy has an internal rate limiter, and it’s fine to just let it do its thing.
Why’s that? Can’t you just use xcaddy to make a build, including any plugins you need? Even easier if you’re using a Docker image.