Kip CroninFrom 10 February 2027, Let's Encrypt certificates will last 64 days instead of 90 by default. If certbot or another ACME client already renews them automatically, you probably don't need to change anything. Run sudo certbot renew --dry-run once to confirm. What breaks is anything that assumes 90 days: a renewal date set by hand, a calendar reminder, or an expiry alert set to 30 days.
What Let's Encrypt announced
On 7 October 2026 Let's Encrypt published the schedule:
| Date | Change |
|---|---|
| 14 Oct 2026 | Staging issues 64-day certificates, so you can test now |
| 10 Feb 2027 | Default certificates last 64 days. Authorization reuse drops from 30 days to 10 |
| 2028 | Default lifetime planned to drop to 45 days; authorization reuse drops to 7 hours |
Two things don't change. Certificates you already have keep their lifetime, and Let's Encrypt won't revoke them as part of this. The post also says the change "will not affect ACME endpoints or our issuance chains". Let's Encrypt expects the last 90-day certificate to expire on 11 May 2027.
Why every CA is doing this
This isn't just Let's Encrypt. In April 2025 the CA/Browser Forum, which sets the rules public certificate authorities follow, passed ballot SC-081v3. Certificate issuers voted 25 yes, 0 no, with 5 abstentions; Apple, Google, Microsoft and Mozilla all voted yes. The maximum lifetime of any public TLS certificate falls in steps. Let's Encrypt's profiles page gives the next two: 100 days for certificates issued from 15 March 2027, and 47 days from 15 March 2029. Let's Encrypt is moving below each limit ahead of time. Paid certificates will follow the same limits.
Let's Encrypt already offers shorter lifetimes if you ask for them. The tlsserver profile issues 45-day certificates and shortlived issues 160-hour ones. If you already chose one of those, the February change doesn't touch you.
Will your renewals still work?
For certbot, it depends on the version. Check yours with certbot --version.
| Certbot version | When it renews | With a 64-day certificate |
|---|---|---|
| Before 4.0.0 (Ubuntu 24.04's apt package is 2.9.0) | When 30 days are left | Renews around day 34. Works |
| 4.0.0 (Ubuntu 26.04's apt package is 4.0.0) | When "less than 1/3rd of its lifetime remains" | Renews around day 43. Works |
| 4.1.0 and later | Asks the CA via ACME Renewal Info (ARI), "typically… around 2/3rds of the certificate's lifetime" | Let's Encrypt picks the time. Works, and it's what Let's Encrypt recommends |
The day numbers are our arithmetic from each rule, not measurements. Let's Encrypt's own advice: if your client supports ARI, "you should be all set". If your renewals are "hard-coded to a date from expiration", change them to renew at about two-thirds of the lifetime.
Other ACME clients (acme.sh, Caddy, Traefik, cert-manager and the rest) have their own rules. Check whether yours supports ARI or renews at a fraction of the lifetime rather than a fixed number of days.
A five-minute check
The certbot commands come from certbot's user guide; systemctl list-timers is standard systemd. Run them on each machine that holds a certificate:
certbot --version
sudo certbot certificates
sudo certbot renew --dry-run
systemctl list-timers '*certbot*'
grep -H renew_before_expiry /etc/letsencrypt/renewal/*.conf
certbot certificateslists each certificate and its expiry date.renew --dry-run"uses the Let's Encrypt staging server", so since 14 October it requests a 64-day certificate. Nothing on your server changes.list-timersshows that a renewal timer exists and when it next runs. If nothing is listed, find out what runscertbot renewon that machine (a cron entry, a container) before February.- The
grepfinds any certificate with a hand-set renewal window. Since 4.1.0, an ARI answer overrides a laterrenew_before_expiry.
Three things that will bite
- Expiry alerts set to 30 days. With certbot 4.x, a 64-day certificate still has about 21 days left when it renews. An alert at "30 days left" would then fire every cycle. Move it to around 10 days, so it only fires when renewal has actually failed.
- Manual renewals. If you renew by hand with a DNS TXT record every quarter, you'll be doing it every two months, then every six weeks. That's the time to automate it.
- Copies of the certificate in other places, such as a router, a NAS or a reverse proxy on another box. They need a deploy hook or a sync job that runs after each renewal, not a calendar note.
Our take: this is one item in the first issue of HackHour Weekly, not a whole issue, for a reason. If your renewals are already automatic, the February change won't affect you. The work is finding the one machine where they aren't.