This article was written with the help of AI. We used an AI assistant to draft it, then checked every date and claim against Let's Encrypt's announcement and the relevant standard. Sources are linked throughout.
Let's Encrypt 64-day certificates become the default on February 10, 2027. In its October 7, 2026 announcement, Let's Encrypt says certificates issued or renewed from that date will be valid for 64 days instead of 90. Existing certificates are not revoked, and it expects the last 90-day certificate to expire on May 11, 2027.
For most websites this is a non-event: the renewal tool notices the shorter lifetime and renews sooner. The sites that break are the ones with a script, a cron job or a monitoring rule that someone wrote years ago assuming 90 days.
What Changes
- 64-day lifetime by default for new certificates from February 10, 2027. The change went live in the Let's Encrypt staging environment on October 14, 2026, so you can test against it now.
- Shorter authorization reuse. After a client proves it controls a domain, Let's Encrypt lets it reuse that proof for a while. That window drops from 30 days to 10. Most clients need no change unless they depend on reuse.
- More to come. The earlier plan moves the default to 45 days in 2028, and reuse shrinks to seven hours that year. Shorter options (45 or 6 days) are already available by choosing a certificate profile.
How Renewal Scripts Break
Three assumptions show up again and again in home-grown renewal setups:
- "Renew when 80 days remain." A 64-day certificate never has 80 days left, so this either renews on every run or never fires, depending on how the check is written. Both are bad.
- "Expiry is issue date plus 90 days." The script thinks it has 26 more days than it does and plans the next renewal after the certificate has already expired.
- "Alert at 30 days left." A monitor tuned for 90-day certificates may go quiet or start firing constantly.
None of these fail on the day of the change. They fail a few weeks later, when a visitor or an app gets a certificate warning.
The Fix: Let the Certificate Authority Pick the Time
ACME Renewal Information, or ARI, is a standard published as RFC 9773 in June 2025. It lets the certificate authority publish a suggested renewal window for each certificate, and a client that supports it renews inside that window instead of guessing. Let's Encrypt recommends it directly: with ARI, it can tell your client when to renew.
If your client cannot use ARI, Let's Encrypt's advice is to renew at about two-thirds of the certificate's lifetime. Calculate that from the certificate you actually have. Do not swap one hard-coded number for another.
Do Not Forget the Last Step: Deployment
A renewed certificate on disk does nothing until every place that serves it has the new one. Check that the reload or deploy step runs after each renewal and reaches every web server, load balancer, API gateway and CDN that presents the certificate. Monitor the certificate visitors actually receive, from outside your network, not just the file on the server.
Check Your CAA Records
A CAA record in DNS lists which certificate authorities may issue certificates for your domain. It does not affect timing, but if it names only another CA, a Let's Encrypt renewal will be refused. Let's Encrypt's CAA page says the value to allow it is letsencrypt.org, for example:
example.com. IN CAA 0 issue "letsencrypt.org"If you use more than one CA, list all of them. If you have no CAA record at all, any CA may issue, and nothing needs to change for renewals.
A Checklist to Run Before February 10
- List every public certificate: hostname, issuer, expiry, renewal tool, deploy step, and who gets the alert if it fails.
- Search scripts and monitors for 90, 80, 60 and 30 used as day counts.
- Check your ACME client's documentation for ARI support, and confirm it is turned on.
- Run a full renewal against the staging environment, including the deploy and reload, and confirm the test hostname serves the new certificate.
- Confirm CAA records allow the CA your client uses.
- Make failures loud. A failed renewal should open a ticket or reach a watched inbox with the hostname and current expiry. A browser warning is not monitoring.
If you are not sure what certificates you have, our certificate monitoring watches the certificate each site actually presents and warns before it expires.
Sources
- Let's Encrypt: 64-Day Certificate Lifetimes Coming Feb 2027 (October 7, 2026)
- RFC 9773: ACME Renewal Information (ARI) Extension
- Let's Encrypt: Staging Environment
- Let's Encrypt: Certificate Authority Authorization (CAA)
Common questions
Do I need to replace my current Let's Encrypt certificates?
No. Let's Encrypt says it will not revoke valid certificates as part of this change. Certificates issued before February 10, 2027 keep their 90-day lifetime, and the last of them should expire around May 11, 2027.
Will Certbot or my hosting company handle this automatically?
Usually, yes. Clients that renew based on the certificate's real expiry, or that support ACME Renewal Information (ARI), need no change. The risk is in custom scripts, cron jobs and monitoring rules that assume 90 days.
When should a 64-day certificate renew?
If your client supports ARI, let Let's Encrypt tell it. If it does not, Let's Encrypt suggests renewing at about two-thirds of the certificate's lifetime, which is roughly 21 days before a 64-day certificate expires.
Is this the last change?
No. Let's Encrypt's earlier plan sets default lifetimes at 45 days in 2028, and authorization reuse drops to seven hours that year. Fixing the automation now covers both.
