i upgraded to 2.4.3 and the server i took out of the load balancer is down, it doesn’t serve request anymore. After i replaced caddy with the new version and reloaded the service i saw this error:
6 [ERROR] While deleting old OCSP staples, unable to load staple file: unable to decrypt data for ocsp/
many of them for each domain.
After that, i couldn’t access any domain on the server. the logs don’t show any error. I even tried to put back the old 2.3 version, not working. I restearted caddy, not working
btw, we use proxy-protocol and redis storage if that helps
yes, that seems to be the issue. will use 2.3 until i find a fix. i’ll set renewal_window_ratio=1 on the old caddy version.
Beginner question: how do I set this value using Caddyfile not json? Or this is not available on 2.3.0? Unfortunately i can’t use other version because of redis issue
Yep, absolutely. Even if you’re using a Caddyfile.
I haven’t tested these instructions, I probably got these slightly wrong, be sure to test in a staging or dev environment first.
First, do a GET /config/ to get Caddy’s current config:
curl "http://localhost:2019/config/"
Then identify the path to the relevant TLS automation policy. It should be at apps/tls/automation/policies/N, where N is an index into the array (0-based as usual).
If you find it (look at subjects for your affected domain name) then you can do:
Thanks a lot @matt Once this is over I’ll try to convince my company to donate. Right now the only thing that worked is to delete the certificate completely, restart caddy and follow the link to issue a new one.
All other tries with deleting the OCSP and waiting failed (waited 3 hours).
Thank you. I tried this but even if it start to renew some certificates, about 10 in 10 minutes, it starts to renew again the same certificates, for ex. one certificate was renewed 3 times. Is that normal?
Also, i tried to set it as 0.995 and after 100 or so slows to 1 per 15 minutes.
We were previously using a version of Caddy earlier than v2.4.2 and upgraded to v2.4.6 today. Do you know if Caddy will automatically handle the certificate revocations, even if the certs were issued with the earlier version of Caddy?
Yes, there’s nothing inherently different about the certificate data itself, it was just an implementation bug prior to v2.4.2 that caused it to not properly react when it found out about revocation. The relevant commit is here:
Yes; like I said, turn off the setting immediately after it gets the certificate, otherwise you’ll hit rate limits. It will always renew certificates at every scan with that setting. Not suitable for most deployments tbh.
Probably because it would always look at those first 10, attempt renewing all of them, then not do any of the rest because Caddy’s internal rate limiter prevented doing more than 10, rinse, repeat.
makes sense. but with 0.995 why does it renew it so slow after renewing about 120 certificates? right now it renews like 5 every hour lately, for the past 4 hours.
I don’t think that field supports floating point values, only integers. It probably got converted to an int as 0.
Either way, easiest way to force a renewal is to just remove the certificates from storage and reload Caddy. It’s clear the renewal_window_ratio option isn’t sufficient to change to make all certs get renewed.