Let's Encrypt moves to 64 days from 10 February 2027: how many more SSL renewals in 2027
From 10 February 2027, classic Let's Encrypt certificates will last 64 days instead of 90. Annual renewal counts for 1, 10 and 100 certificates, and what to automate beforehand.
UptimeMag editorial team · 11 October 2026 · 3 min read

From 10 February 2027, anyone using Let's Encrypt with the classic profile will see their certificates last 64 days instead of 90. Let's Encrypt has announced: "On February 10, 2027, all Let's Encrypt subscribers will move to certificates with 64 day lifetimes by default unless they select an even shorter lifetime (45 or 6 days, as previously announced)". For anyone running even a single server, this means reviewing cron jobs and renewal scripts before the new rule kicks in. For anyone managing a hundred, it means redoing the maths on how many times a year the automation runs.
Dates to mark in your calendar
| Date | What changes |
|---|---|
| 14 October 2026 | Let's Encrypt starts issuing 64-day certificates in staging, to allow testing |
| 10 February 2027 | The classic profile switches to 64 days; domain authorisation reuse drops from 30 to 10 days |
| 11 May 2027 | Expected expiry date of the last 90-day certificate |
| 16 February 2028 | The classic profile will move to 45-day certificates, with a 7-hour authorisation reuse period |
Certificates already issued are not affected: Let's Encrypt makes clear it will not revoke valid certificates during the transition.
How many renewals a year, number by number
With a 90-day certificate, renewing every 60 days (the historically recommended practice), you get around 6 renewals a year per domain. With a 64-day certificate, renewing at roughly two-thirds of the lifetime as Let's Encrypt now advises, you renew every 42-43 days: that means going from 6 to roughly 8-9 renewals a year per certificate.
Multiplying by the certificate fleet you manage:
| Certificates managed | Renewals/year at 90 days (every 60 days) | Renewals/year at 64 days (every ~43 days) |
|---|---|---|
| 1 | ~6 | ~8-9 |
| 10 | ~60 | ~85 |
| 100 | ~600 | ~850 |
It's not a doubling, but for anyone managing a fleet of 100 domains, the difference shows up straight away in cron logs, alerts and, if the renewal isn't silent, in any failure notifications.
What to automate before February
Let's Encrypt's advice is practical, not theoretical: fixed deadlines based on 90 days need updating, because the jump to 64 days shifts the renewal frequency from four times a year to roughly 12-13 times a year per certificate if things go all the way down to the 45 days planned for 2028. Specifically, for the 2027 transition:
- If your ACME client supports ARI (ACME Renewal Information), no manual action is needed: the protocol itself tells the client when to renew, rather than relying on a fixed date.
- If renewals are hard-coded to a date relative to expiry, they need updating to trigger at roughly two-thirds of the certificate's lifetime, as Let's Encrypt itself recommends.
- To work out whether you're exposed, search your cron jobs, wrapper scripts and runbooks for numbers like 83, 80 or 60, which are typical of calculations tuned for 90 days.
- It's worth testing the new behaviour in staging now, since the staging environment has been issuing 64-day certificates since 14 October 2026.
- If you haven't designed your client to make use of domain authorisation reuse, there's nothing to change on that front: the cut from 30 to 10 days only affects those who explicitly rely on that window.
Finally, this change of scale is also a good opportunity to automate certificate reload and deployment after renewal, and to add an alert for renewal failures: with more cycles a year, a single missed renewal matters less in relative terms, but it happens more often if nobody notices.
Written with the help of artificial intelligence and checked by the editors (EU AI Act, art. 50).