Let’s Encrypt cuts certificate lifetimes to 64 days and forces self-hosters to rework their renewals
On October 7, 2026, Let’s Encrypt announced that every certificate will default to a 64-day lifetime from February 10, 2027. Check now that your ACME client supports ARI, or that your renewals are not hard-coded to fixed dates.
On October 7, 2026, Let’s Encrypt announced that every certificate it issues will default to a 64-day lifetime starting February 10, 2027. The staging environment switches to 64-day certificates on October 14, 2026, and the last 90-day certificate is expected to expire on May 11, 2027. Why it matters: most self-hosters never read their renewal logs while things work — and that is exactly the behavior this change punishes.
What actually changes
The rule is easy to state. From February 10, 2027, every certificate issued or renewed by Let’s Encrypt will carry a 64-day validity, unless you explicitly choose a shorter profile — 45 days or 6 days, as announced back on December 2, 2025. The authority will not revoke any valid certificate along the way: the transition happens by attrition, renewal after renewal.
Two dates matter for preparation. On October 14, 2026, the staging environment flips to 64 days, which is your window to test the renewal chain without touching production. On May 11, 2027, the last 90-day certificate expires; after that, nobody holds a long-lived certificate anymore. If your automation is broken, you discover it at that moment at the latest — probably on a Sunday evening.
The rationale is blunt. Shorter lifetimes shrink the window in which a compromised key or a mis-issued certificate stays exploitable. As a nonprofit, Let’s Encrypt frames this as part of its mission to advance security for the whole Web, even when it forces its users to rework their tooling.
Why 64 days, and why it keeps moving
This is a step, not a stop. Let’s Encrypt already signalled on December 2, 2025 that the end target is a default lifetime of 45 days in 2028. The move to 64 days is therefore an intermediate plateau, meant to prepare infrastructure for more frequent renewals without jumping straight to the most aggressive cadence.
The underlying reasoning is industry-wide. The longer a certificate lives, the longer a compromised private key remains usable, and the longer the gap between a faulty issuance and its detection. Browsers and large CAs have been pushing toward short lifetimes for years; Let’s Encrypt is simply accelerating the timetable for the ecosystem it serves.
Two collateral changes ride along. The validation reuse period drops from 30 days to 10 days, then to 7 hours in 2028, anticipating a 2029 regulatory reduction and removing the need for CAA rechecking. Rate limits are unchanged. Unless your client was written to depend on validation reuse, there is nothing to do on that front.
Where this trajectory comes from
The move to 64 days is part of a continuous compression of certificate lifetimes. A decade ago, an SSL certificate routinely lived one to two years. Browsers then forced the descent: two years, then 398 days, then 90 days, which became the de facto standard thanks to Let’s Encrypt. The 64-day step prepares the way for the 45-day default in 2028, already announced.
Why the obsession with short lifetimes? Because the cost of a compromised key is proportional to how long it stays valid. A certificate that lives two years lets an attacker exploit a stolen key for months. At 64 days, the window closes in two months; at 45 days, in six weeks. Now that ACME automation has made renewal nearly free, a long lifetime protects nobody: it only benefits the attacker and poorly configured installs.
The consequence for the self-hoster is direct. Certificate lifetime is no longer a variable you choose but a constraint that keeps dropping. Anyone who tunes their automation for 90 days will have to retune for 64, then for 45. In practice, this splits the world in two: Caddy and Traefik renew automatically and implement ARI, so they will keep working with zero intervention, while a hand-rolled certbot cron with a hard-coded threshold is the profile most likely to break. The difference is not the tool but whether renewal is event-driven or date-driven.
There is a quieter lesson in the timing. Let’s Encrypt is flipping staging on October 14, 2026, roughly four months before production changes, precisely so that teams can fail safely. The self-hosters who treat that date as a real deadline — test the chain, watch the logs, alert on failure — will sail through February 10. The ones who skip it will meet the change as a surprise outage rather than a non-event.
What breaks if you do nothing
The risk is not in well-configured clients but in frozen automation. Two cases dominate among self-hosters.
The first is a renewal hard-coded to a fixed date. Plenty of cron jobs, wrapper scripts and runbooks renew “N days before expiry” using values tuned to the old 90-day lifetime. The numbers to hunt for are 83, 80 or 60. With a 64-day certificate, a renewal scheduled at day minus 83 never fires, and the certificate lapses.
The second is a client that does not support ARI, the ACME Renewal Info. ARI lets the authority tell the client when to renew, which makes the client indifferent to the exact lifetime. If your client supports ARI, the switch is transparent. If not, you must explicitly renew at roughly two-thirds of the lifetime, which also lays groundwork for the 45-day default in 2028.
There is also an invisible side effect: validation reuse shrinking from 30 to 10 days. A homegrown tool that leans on that reuse to avoid re-validating a domain on every renewal may start failing more often. The official guidance is not to depend on it.
What to check right now
Preparation comes down to four moves, in order.
- Identify your ACME client and check its documentation for ARI support. Caddy, Traefik, a recent certbot, Nginx Proxy Manager and most maintained clients implement it; homegrown scripts rarely do.
- Hunt for hard-coded values in your cron jobs and scripts. A
grep -rn "83\|80\|60"over your deploy folders surfaces renewals tuned to the old lifetime. - Test in staging after October 14, 2026. The staging environment will issue 64-day certificates before production does, which is the only way to validate your chain without risking a real expiry.
- Add alerting for renewal failures. Automation that fails silently is the number one cause of expirations; a cron job that emails when a certificate nears its end is enough.
Most self-hosters running a modern reverse proxy will have nothing to change. The real hazard is concentrated in old installs, hand-rolled scripts and services that have not been touched in months.
Verdict
If your renewals go through an up-to-date Caddy, Traefik, certbot or Nginx Proxy Manager and you have hard-coded nothing, the move to 64 days is a non-event: test in staging after October 14 and make sure failure alerting exists. If you run a homegrown script, a client without ARI, or 83/80/60 values in your cron jobs, fix the renewal to two-thirds of the lifetime now and drop any reliance on validation reuse — otherwise May 11, 2027 marks the end of your last 90-day certificate and, likely, an avoidable outage.