Let's Encrypt is dropping certificate validity from 90 days to 64 days starting February 2027. If you're like me, your first thought was probably "64 days is still 64 days, what's the big deal?"
The big deal is that a lot of renewal scripts make assumptions about timing that break when you compress the cycle.
The Math Problem
With 90-day certs, certbot's default 30-day renewal window meant renewals happened around day 60. That gave you a comfortable 30-day buffer. With 64-day certs, if you keep that same 30-day window, you're renewing at day 34. That's only a 4-day overlap if something goes wrong.
Most people will adjust the window to 20 days, which means renewals at day 44. Better, but still tighter than before.
One Line That Breaks
Here's a renewal check I've seen in a few places:
if [ $(openssl x509 -enddate -noout -in cert.pem | cut -d= -f2) -lt 30 ]; then
certbot renew
fi
This works fine when you're checking 30 days before expiry on a 90-day cert. But with 64-day certs, you might want to check 20 days before expiry instead. The number itself isn't magic—it's just a threshold. The real question is: what's your actual renewal schedule, and does your check match it?
A Cleaner Approach
Instead of hardcoding days, calculate the renewal window as a percentage of the cert lifetime:
# Get cert lifetime in seconds
LIFETIME=$(($(date -d "$(openssl x509 -enddate -noout -in cert.pem | cut -d= -f2)" +%s) - $(date -d "$(openssl x509 -startdate -noout -in cert.pem | cut -d= -f2)" +%s)))
# Renew at 70% of lifetime (works for any cert duration)
RENEWAL_THRESHOLD=$(( $(date +%s) + (LIFETIME * 30 / 100) ))
if [ $(date -d "$(openssl x509 -enddate -noout -in cert.pem | cut -d= -f2)" +%s) -lt $RENEWAL_THRESHOLD ]; then
certbot renew --quiet
fi
This scales whether you're on 90-day, 64-day, or some future 45-day cert.
What About Monitoring?
Most monitoring tools check "days until expiry" against a static threshold. If you're alerting at 30 days, that worked fine for 90-day certs (you'd get alerted once per cycle). With 64-day certs and a 20-day renewal window, you might want to alert at 15 days instead—just enough time to catch a failed renewal before the cert actually expires.
Check your alerting config. It's probably hardcoded somewhere.
The change itself isn't dramatic. It's just a reminder that "90 days" was never the point—the point was having enough buffer to handle failures. When the cycle compresses, the buffer compresses too. Adjust accordingly.
Top comments (1)
Good breakdown. One thing worth adding to the checklist: the renewal check is only half the pipeline. A renewed cert sitting on disk does nothing until the service picks it up, so pair your renew with a deploy hook that reloads nginx, haproxy, or whatever terminates TLS. I have seen teams automate renewal perfectly and still serve an expired cert because nothing reloaded the process. Shorter lifetimes just make that gap more likely to bite.