On February 10, 2027, the default Let’s Encrypt certificate shrinks from 90 days to 64. Most automated setups won’t notice. A few will renew with days to spare, or after the certificate has already expired. Here is how to tell which kind you run.
From February 10, 2027, every certificate Let’s Encrypt issues or renews will be valid for 64 days by default, down from 90. Nothing changes for certificates you already have: Let’s Encrypt will not revoke them, and it expects the last 90-day certificate to expire on May 11, 2027. Its staging environment was set to switch to 64-day certificates on October 14, 2026, so you can test now (announcement).
If your client supports ACME Renewal Information (ARI) and renews on its own, you very likely have nothing to do. If anything in your setup renews on a fixed number of days, read on: a job that renews every 60 days leaves a 64-day certificate four days of margin, and one that waits 80 days renews it after it has expired.
What changes, and when
The change is the first of two steps that Let’s Encrypt announced in December 2025, ahead of the industry-wide limits in the CA/Browser Forum’s Baseline Requirements. It applies to the default profile, classic, which is what every client gets unless it asks for another.
| Default profile | Until February 9, 2027 | From February 10, 2027 | From February 16, 2028 |
|---|---|---|---|
| Certificate lifetime | 90 days | 64 days | 45 days |
| Authorization reuse | 30 days | 10 days | 7 hours |
Each change reaches the staging environment first, and each one reaches you at your first renewal after its date, since it only applies to new certificates.
What stays the same, according to the announcement: the ACME endpoints, the issuance chains, and the rate limits. You can’t opt back into 90 days. The only choices are shorter: the opt-in tlsserver profile already issues 45-day certificates, and shortlived issues certificates valid for 160 hours, a little over six days (profiles).
Who needs to do something
Let’s Encrypt’s advice comes in two parts. If your renewals are automated and your client supports ARI, “you should be all set”, because ARI lets the CA tell your client when to renew. If your renewals are “hard-coded to a date from expiration”, change them to renew at about two-thirds of the lifetime instead. How many sites this touches: our SSL certificate statistics give Let’s Encrypt’s share of the top sites’ certificates.
The trouble is any rule written in days. Here is how common ones fare as the lifetime shrinks:
| Renewal rule | 90-day certificate | 64-day certificate | 45-day certificate |
|---|---|---|---|
| Renew 60 days after issue | 30 days left | 4 days left | Expired 15 days earlier |
| Renew 80 days after issue | 10 days left | Expired 16 days earlier | Expired 35 days earlier |
| Renew 83 days after issue | 7 days left | Expired 19 days earlier | Expired 38 days earlier |
| Renew with 30 days left | 30 days left (after 60) | 30 days left (after 34) | 30 days left (after 15) |
| Renew at two-thirds of the lifetime | 30 days left | 21 days left | 15 days left |
“Renew with 30 days left” keeps working, but at 45 days it renews twice as often as it needs to. A rule tied to the lifetime is the only one that stays sensible at every step, and asking the CA through ARI is better still.
The 83, 80 and 60 in the table are not invented: Let’s Encrypt suggests searching cron jobs, wrapper scripts and runbooks for exactly those numbers if you aren’t sure what yours do.
Check your setup
Certbot
Certbot is in good shape if it is reasonably current. Since version 4.0.0 (April 2025) it renews when less than a third of a certificate’s lifetime is left, instead of the fixed 30 days before expiry it used until then. Since 4.1.0 (June 2025) it also asks Let’s Encrypt through ARI, which the changelog says “will typically cause renewal at around 2/3rds of the certificate’s lifetime”. Even the old 30-day rule renews a 64-day certificate after 34 days, in good time.
Two things are worth a look:
certbot --version
sudo grep -r renew_before_expiry /etc/letsencrypt/renewal/A renew_before_expiry line in a certificate’s renewal file overrides the default. Something like 30 days still works. A value close to the lifetime, such as 60 days, makes Certbot renew a 64-day certificate every four days; delete the line to go back to the default.
Then run sudo certbot renew --dry-run. According to Certbot’s documentation, it renews every certificate against the staging server, including domain validation and your pre- and post-hooks, without saving anything to disk; add --run-deploy-hooks to run the deploy hooks too. It tests that renewal works, not when it happens.
acme.sh
acme.sh changed its defaults this year, so the version matters. Up to 3.1.2, it renewed 60 days after issue by default: four days before a 64-day certificate expires. Version 3.1.3 (April 2026) moved the default to 30 days, and 3.1.4 (July 2026) added ARI, on by default, with the cron job running every six hours to follow the CA’s renewal window.
acme.sh --version
acme.sh --info -d example.com | grep -E 'Le_RenewalDays|Le_NextRenewTimeStr'Le_NextRenewTimeStr is when acme.sh plans to renew. Le_RenewalDays only appears when someone pinned the schedule with --days; without ARI, or with it turned off (NO_ARI=1), that number decides alone. If it says 60 or more, upgrade with acme.sh --upgrade and re-issue with a schedule that counts back from expiry: since 3.1.4, a negative value such as --days -21 renews 21 days before the certificate expires. Recent versions print a warning of their own when a planned renewal falls after the certificate’s expiry, and suggest the same fix.
Caddy
Caddy renews when a third of a certificate’s lifetime is left. That is the default of its renewal_window_ratio option, 0.3333, and a ratio follows the certificate wherever its lifetime goes. Its certificate library, CertMagic, also supports ARI, so the CA can suggest a window too. Unless your Caddyfile sets a small renewal_window_ratio (a ratio of 0.1 leaves about six days on a 64-day certificate), there is nothing to change.
cert-manager on Kubernetes
By default cert-manager renews “2/3 through the X.509 certificate’s duration”, measured on the certificate it actually received, according to its documentation. The thing to look for is spec.renewBefore, a fixed duration before expiry. The same page recommends spec.renewBeforePercentage instead, which scales with the issued certificate, to avoid renewal loops when a certificate comes back shorter than requested, as a Let’s Encrypt certificate will from February 10, 2027 if spec.duration asks for 90 days.
kubectl get certificates -A -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,RENEW_BEFORE:.spec.renewBefore,PERCENT:.spec.renewBeforePercentage,RENEWAL:.status.renewalTime'A renewBefore of 720h (30 days) still works on 64 days. Anything near 1536h (64 days) or more does not.
A host, CDN or control panel
If your hosting company, CDN or control panel gets Let’s Encrypt certificates for you, the renewal timing is theirs to get right, and there is nothing to configure. It is still worth knowing which of your sites work this way, and checking one of them after February 10, 2027: the SSL certificate checker shows the lifetime of the certificate a site serves, so a 64-day certificate there means the platform has switched and is renewing.
Cron jobs, scripts and runbooks
Search for the numbers Let’s Encrypt names, on every machine that renews certificates:
# Hard-coded renewal intervals in cron, systemd timers and scripts
sudo grep -rnwE '60|80|83' /etc/cron* /var/spool/cron /etc/systemd/system /usr/local/bin 2>/dev/null
# ACME clients' own settings
sudo grep -rn 'renew_before_expiry\|Le_RenewalDays\|renewBefore' /etc/letsencrypt /root/.acme.sh ~/.acme.sh 2>/dev/nullNot every match is a problem: a 60 can be a minute or a port. What you are looking for is a schedule like “renew every 60 days” or --days 80, or a runbook step that says to renew a month before expiry by hand. Replace a fixed interval with your client’s own renewal check, run daily or twice a day, and let it decide.
Authorization reuse drops from 30 days to 10
When Let’s Encrypt validates your control of a domain, it can reuse that authorization for later orders. From February 10, 2027 that window falls from 30 days to 10, and in 2028 to seven hours. Let’s Encrypt says that unless you have “specifically designed your ACME client to rely on validation reuse”, you won’t need to change anything.
In practice, it means almost every renewal will validate the domain again, so whatever validation depends on must work every time, not just most of the time:
- HTTP-01 needs port 80 reachable from the internet at each renewal. A firewall rule, a redirect to a login page or a maintenance page can break it.
- DNS-01 needs working credentials for your DNS provider at each renewal. A token that expires once a year will now fail a renewal, not a rare re-validation.
Test against staging
Let’s Encrypt set staging to issue 64-day certificates from October 14, 2026, so a staging certificate should show you the new lifetime months early. Staging certificates are signed by test roots that browsers don’t trust, and staging has its own rate limits and accounts, so test on a spare hostname or keep staging certificates away from production files.
Point the client you use at the staging directory, https://acme-staging-v02.api.letsencrypt.org/directory:
- Certbot:
--test-certgets a real staging certificate you can inspect (--dry-rundoesn’t keep one). - acme.sh:
--staging(or--server letsencrypt_test). - Caddy: the global option
acme_ca https://acme-staging-v02.api.letsencrypt.org/directory. - cert-manager: an
IssuerorClusterIssuerwhoseserveris the staging URL.
Then read the dates of the certificate you got:
openssl x509 -in cert.pem -noout -startdate -enddateA notAfter 64 days after notBefore means you got the new lifetime. Your renewal logic’s next decision is then the thing to check: run the client’s renewal command again and confirm it says the certificate is not yet due, instead of renewing it straight away or planning to wait 60 days.
Watch the certificate, not just the job
Renewal can succeed while the server keeps sending the old certificate: nothing reloaded it, or the new file went to the wrong path. And with less time between renewal and expiry, a quiet failure has less time to be noticed. Two habits help:
- Alert on the certificate’s lifetime, not on a fixed number of days. A 64-day certificate is normally renewed with about 21 days left, so an alert at 14 days means renewal is already a week late. Set the alert below your normal renewal point, so that it only fires when something went wrong.
- Check what the server actually sends, from outside, the way a visitor sees it. The SSL certificate checker shows a certificate’s lifetime and when renewal would normally be expected, and says so when that date has passed and the old certificate is still served. Expiry Watch checks your domains every day and, for certificates this short, learns when each domain normally renews and emails only when a renewal looks late, then again as expiry gets close. It’s free for up to 10 domains.
Let’s Encrypt stopped sending expiry emails in June 2025, so this is no longer something it will do for you. For one-off checks from a terminal, see how to check a certificate’s expiry date.
Common questions
Will my current 90-day certificate stop working early?
No. Let’s Encrypt is not revoking or shortening anything already issued. Each certificate keeps its 90 days, and the next one it gets after February 10, 2027 will last 64.
Can I keep getting 90-day certificates?
No. The change applies to all subscribers. You can choose a shorter lifetime (45 days or about 6 days) through a profile, but not a longer one.
Do I need to update my intermediate certificates or trust stores?
No. Let’s Encrypt says the change does not affect its issuance chains or its ACME endpoints.
Will I hit rate limits by renewing more often?
Let’s Encrypt says rate limits are not affected by this change. A client that renews once at two-thirds of the lifetime makes a few more orders a year than before, not many.
Why is Let’s Encrypt doing this?
Shorter lifetimes limit how long a compromised key or a mis-issued certificate can be used. The industry rules are moving the same way: publicly trusted certificates issued from March 15, 2029 may last at most 47 days (details). The shorter authorization reuse is, in Let’s Encrypt’s words, to comply with a 2029 reduction in validation reuse periods.
Sources
All sources were checked on October 20, 2026.
- 64-Day Certificate Lifetimes Coming Feb 2027, Let’s Encrypt, October 7, 2026: the date, the staging date, the last 90-day expiry, ARI and hard-coded renewal advice, the 83, 80 and 60 search tip, authorization reuse, and what does not change.
- Decreasing Certificate Lifetimes to 45 Days, Let’s Encrypt, December 2, 2025: the full timeline, including February 16, 2028.
- Upcoming Features, Let’s Encrypt, last updated July 22, 2026.
- Profiles, Let’s Encrypt documentation, last updated October 4, 2026:
classic,tlsserverandshortlived. - Staging Environment, Let’s Encrypt documentation.