TL;DR - Let's Encrypt announced on 7 October 2026 that every subscriber gets 64-day certificates by default from 10 February 2027, with staging starting to issue them on 14 October 2026. Shorter profiles of 45 and 6 days exist and stay opt-in, so nobody is being pushed onto a six-day certificate. What actually breaks is not the certificate, it is the renewal arithmetic hardcoded into your cron jobs, systemd timers and wrapper scripts. An offset of 83 or 80 days, written back when certificates lasted 90 days, is now larger than the entire certificate lifetime, so your tooling decides renewal is already overdue and tries to renew on every single run. What you need to do: grep for 83, 80 and 60 this week, confirm your ACME client supports ACME Renewal Info (ARI), and spend the 14 October staging window proving issuance and deploy still work.
By The Numbers
| Item | Value |
|---|---|
| Default certificate lifetime from 10 February 2027 | 64 days |
| Lifetime it replaces | 90 days |
| Announcement | 7 October 2026, by Sarah Gran |
| r/sysadmin thread | 637 points, 381 comments |
| Shorter profiles available | 45 and 6 days, opt-in only |
| Staging starts issuing 64-day certs | 14 October 2026 |
| Renewal offsets that will bite | 83, 80 and 60 |
| Certbot's own default renewal point on a 64-day cert | Day 43 (two thirds of lifetime) |
I read the Let's Encrypt announcement on the train into the office and did what I always do with a blog post, which is open the reply thread before I read the post. That thread had 637 points and 381 comments on it and it was the biggest operational thread of the week in r/sysadmin, which is the tell. When a certificate authority change becomes the top operational conversation, the change has landed in people's cron jobs.
The announcement itself is short and calm. From 10 February 2027, all Let's Encrypt subscribers get 64-day certificates by default instead of 90-day ones. Shorter profiles of 45 and 6 days exist, carried through the profiles system announced back in December 2025, and they stay opt-in. Nobody is being forced onto a six-day certificate, and I want to be clear about that because the reply thread had plenty of people assuming the worst reading.
What the post also says is that if your client supports ACME Renewal Info, which the CA calls ARI, you are all set. That sentence is doing a lot of work in a short paragraph, and I spent the rest of the morning reading the source of three popular clients to find out whether it is true.
What sat with me afterwards was this. The people who are going to have a bad February are not the ones with a naive client. Modern clients already work out their renewal window from the certificate's actual lifetime. The people who will have a bad February are the ones with a cron job that somebody wrote in 2021, that has been silently working ever since, and that contains the number 60.
Let me walk you through what actually changed, what those three numbers do to a 64-day certificate, which clients really support ARI, and how to test it before February arrives.
What Let's Encrypt Actually Changed
Four facts, and they are the whole story.
Default validity drops from 90 days to 64 days on 10 February 2027. Every subscriber. Not a rollout, not an opt-in programme, not a beta.
Staging issues 64-day certificates from 14 October 2026. This is the part that matters for you, because it gives you a four-month window to test against the real thing rather than guessing.
Shorter profiles exist and are opt-in. 45-day and 6-day certificates are available through the profiles system announced in December 2025. You can select them. Nobody selects them for you.
ARI is the escape hatch. Let's Encrypt's position is that if your client understands ACME Renewal Info, the CA can tell the client when to renew and everything works itself out.
Nothing about the protocol changed. Same ACME, same validation, same chain of trust, same browser trust store. That is the entire change.
Why I am not worried about this
Shorter lifetimes are a net win and I want to say so plainly rather than treat every CA announcement as a crisis.
The argument is blast radius. If a private key leaks today, the exposure window is as long as the certificate is valid. Cut that to 64 days and you have cut the worst case by more than a quarter. Push it to 6 days and a stolen key is close to useless within a week, which is a different security posture rather than a cosmetic one.
There is an operational benefit too. Short-lived certificates are a forcing function on automation. Every 90 days, plenty of estates have a certificate that something depends on and nobody remembers what. A tighter cycle surfaces those dependencies while there is still time to fix them.
The work is real, but it is bounded, and most of it is work you should have done anyway.
83, 80 and 60: What Those Numbers Do on a 64-Day Certificate
This is the technical heart of the post, and it is just arithmetic.
Most renewal automation is written as an offset measured backwards from expiry. Renew when this many days remain. Those offsets were tuned against 90-day certificates, and two of the three common values are now larger than the certificate itself.
| Offset you hardcoded | On a 90-day cert | On a 64-day cert | What actually happens |
|---|---|---|---|
| 83 days | renew 7 days after issue | 83 is more than the whole 64-day lifetime | the condition is true at birth, so it renews on every run |
| 80 days | renew 10 days after issue | 80 is more than the whole 64-day lifetime | same, renews on every run |
| 60 days | renew 30 days after issue | renew 4 days after issue | a fresh certificate roughly every 4 days |
The 83 and 80 rows are the dangerous ones, and the mechanism is not subtle. Here is the relevant line from Certbot's own renewal logic in certbot/certbot renewal.py:
config_interval = lineage.configuration.get("renew_before_expiry")
if config_interval is not None:
notAfter = crypto_util.notAfter(cert)
if notAfter < storage.add_time_interval(now, config_interval):
return True
Read that as plain English: if the expiry date is earlier than now plus the interval, renew. On a 64-day certificate, now plus 83 days is always in the future relative to expiry. The condition is permanently true. The certificate renews the moment it is issued, again the next hour, again the next day, forever.
That is not a slow drift into trouble. That is a certificate authority hammering your account with issuance requests, and when it shows up it will look like a rate limit problem rather than a certificate problem.
The 60 row is quieter and almost as bad. Renewing 60 days before expiry on a 64-day certificate means renewing four days after issuance, then again four days after that, roughly fifteen times a month instead of roughly once. No security benefit at all, and you spend rate limit headroom you may badly need during a real incident.
A renewal offset written for a 90-day certificate is not a setting. On a 64-day certificate it is a load-bearing wall with the brick removed.
The good news sits in the same file, a few lines earlier. If you have never set renew_before_expiry, Certbot does not use a fixed offset at all:
lifetime = cert.not_valid_after_utc - not_before
if lifetime.total_seconds() < 10 * 86400:
default_rt = not_before + lifetime / 2
else:
default_rt = not_before + lifetime * 2 / 3
Two thirds of the actual lifetime. On a 64-day certificate that is day 43. Naive clients adapt. That is exactly what Let's Encrypt means when it says modern clients are fine.
What ARI actually does, per client
ARI is the mechanism that lets a certificate authority pull a renewal forward, for example to reissue after an industry-wide revocation. It is specified in RFC 9773, and the short version is that your client asks the CA "when should I renew this certificate?" and the CA replies with a suggested window.
I checked the release notes rather than trusting the summary line, because this is exactly the kind of thing that gets asserted confidently and gets blogged wrong.
Certbot. ARI landed in version 4.1.0 on 10 June 2025. The changelog says certbot renew now checks ARI automatically against any ACME server that supports it, and that for Let's Encrypt certificates this typically causes renewal at around two thirds of the certificate's lifetime, overriding a later renew_before_expiry in the renewal config. One nuance from 4.1.1 in June 2025: Certbot stopped checking ARI during --dry-run, because dry-run talks to staging while the live certificate was issued against production.
Caddy. ARI has been in since version 2.8.0 on 29 May 2024, handled through CertMagic alongside lifetime and revocation status as renewal triggers. Caddy worked this out two years before the rest of us needed it.
acme.sh. ARI landed in 3.1.4 on 17 July 2026, on by default, with the installed cron job changed to run every 6 hours so it can react to the suggested window in time. NO_ARI=1 turns it off.
Now the part that ruins the comforting version of this story, and it is in acme.sh 3.1.5 from 19 September 2026: an explicit --days or --valid-to now outranks the ARI renewal window. The source confirms the nuance. A pinned schedule still yields to a window earlier than the one you asked for, so the CA can pull an urgent renewal forward, but it can never push a pinned renewal back. And a fixed-date --valid-to opts out of ARI entirely and is not renewed automatically at all.
ARI will not save you from a hardcoded offset. In acme.sh, a --days 60 in your cron entry outranks the CA's suggestion. In Certbot, a renew_before_expiry of 83 causes an immediate renewal before the ARI branch is even consulted. That is why this post is a grep and not a reassurance.
The Three Buckets
Sort yourself into one of these and you know how much of the afternoon you need.
A client that supports ARI, and you have never set a manual renewal offset. Caddy, Certbot on 5.x, acme.sh on 3.1.4 or later, most cloud-native setups. Spend 15 minutes confirming rather than assuming. Check the version and grep your own config for pinned values.
A cron job, systemd timer or wrapper script that passes a numeric renewal offset. This is the bucket that will hurt. The greps below find them in minutes. Every hit needs a decision: delete the offset and trust the client, or replace it with a fraction of the lifetime.
Certificates from a managed platform. Load balancers, PaaS platforms, CDN edges. Nothing to fix on your side, because you never controlled the offset. Check your provider's statement rather than poking at your cron job looking for a problem that is not yours.
Five Greps and One Test
Run these on whatever host actually issues your certificates. The first one is the broad sweep.
# 1. The broad sweep: hardcoded day offsets near anything certificate-shaped
grep -rInE '\b(83|80|60)\b' /etc/cron* /var/spool/cron /etc/systemd/system \
/usr/local/bin /opt /srv 2>/dev/null \
| grep -iE 'renew|acme|cert|letsencrypt|tls|cron'
# 2. The flags and config keys that actually control renewal timing
grep -rIn -e '--days' -e '--renew-before-expiry' -e 'renew_before_expiry' \
-e 'checkend' -e 'sleep 60' -e 'NO_ARI' /etc /usr/local /opt 2>/dev/null
# 3. Certbot: pinned lineages
grep -rn 'renew_before_expiry' /etc/letsencrypt/renewal/
# 4. acme.sh: pinned schedules and ARI opt-outs
grep -rn -e 'Le_RenewalDays' -e 'Le_Valid_To' -e 'NO_ARI' \
~/.acme.sh /opt/*.acme.sh /var/lib/acme 2>/dev/null
# 5. What the certificate in front of you actually says
openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -dates
Step 5 matters. Run it on a few hosts and compare notAfter and notBefore against what you expect. A host quietly issuing 64-day certificates three weeks before the switch is a host running staging, a pinned profile, or a second client you forgot about.
Then use the staging window. From 14 October 2026, Let's Encrypt's staging environment issues 64-day certificates, which means you can rehearse the real lifetime rather than guessing at it.
# Certbot, straight at staging. Issues an untrusted certificate on purpose.
sudo certbot certonly --staging -d example.com -d www.example.com \
--agree-tos -m you@example.com
# acme.sh
acme.sh --issue --server letsencrypt_test -d example.com --keylength ec-256
# Caddy, in the global options block of the Caddyfile
# acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
Run it through your real deploy hooks. The staging certificate will not validate in a browser, and that is fine. You are testing whether issuance completes, whether your deploy hook fires, whether the reload picks up the new files, and what your logs look like on the shorter cycle. Do it before 14 October for a longer rehearsal, and again after it so you are testing the actual 64-day behaviour.
Key Takeaways
- 64 days is the new default from 10 February 2027. 45 and 6 day profiles exist but stay opt-in.
- Your renewal arithmetic is the risk, not the certificate. Offsets of 83 and 80 days now exceed the certificate lifetime itself.
- An offset that exceeds the lifetime renews forever. Certbot compares expiry against now plus the interval, so the condition is permanently true.
- Modern clients adapt on their own. Certbot renews at two thirds of the real lifetime when nothing is pinned, which is day 43 on a 64-day certificate.
- ARI does not rescue a pinned offset. Certbot has had it since 4.1.0, Caddy since 2.8.0 and acme.sh since 3.1.4, but an explicit
--daysorrenew_before_expirystill outranks the CA. - Staging starts issuing 64-day certificates on 14 October 2026. That is your rehearsal window.
- Run the greps before someone else runs them for you. Thirty minutes of shell beats an incident on a Saturday.
FAQ
What happens to my Let's Encrypt certificates on 10 February 2027? Existing certificates keep the lifetime they were issued with and do not change length on the day. What changes is what your automation receives the next time it renews, which is why the risk shows up in renewal scripts rather than in the certificate you have already issued.
Do I have to move to 45-day or 6-day certificates? No. Those profiles are available through the profiles system announced in December 2025 and they are opt-in. The default becomes 64 days for everyone. Anyone telling you that certificate authorities are forcing six-day certificates has misread the announcement.
What is ACME Renewal Info and does my client support it?
ARI, specified in RFC 9773, is a mechanism where the client asks the certificate authority when it should renew and the CA replies with a suggested window, which lets the CA pull renewals forward when it needs to. Check your client's changelog. Certbot added it in 4.1.0 in June 2025, Caddy in 2.8.0 in May 2024, and acme.sh in 3.1.4 in July 2026, on by default, with NO_ARI=1 to opt out.
Why do 83, 80 and 60 break but 30 does not? Because the comparison is against days remaining, and 83 and 80 are larger than a 64-day certificate. "Fewer than 83 days remaining" is true the instant the certificate is issued, so renewal fires on every run. A value like 30 stays inside the lifetime, so it still works, it just leaves a much narrower window.
Is it safe to test on staging, and when can I start? Yes. Staging issues untrusted certificates on purpose, which is what you want for rehearsing issuance and deploy hooks. Staging starts issuing 64-day certificates from 14 October 2026. Point Certbot, acme.sh or Caddy at staging today to practise on the existing 90-day cycle, then repeat the test after 14 October against the real lifetime.
Are other certificate authorities doing the same thing? There is no matching announcement to point you at. The 64-day default is a Let's Encrypt change, and I would not assume another provider has moved without reading their own documentation.
How long does the whole audit take? About 30 minutes if you have shell access to the hosts that issue certificates. Fifteen for bucket one, half an hour for bucket two, and for bucket three just read your provider's documentation.
My Take
The number I keep coming back to is 64. Not because it is dramatic, but because it is a number your scripts can get wrong without anyone noticing. Every other figure in this announcement is a date a human can diarise. Sixty-four is a number that lives inside a shell script nobody has opened since the pandemic, and it will be discovered by a monitoring alert at 2am rather than by anybody planning their quarter.
What I like about Let's Encrypt's position is how small the pitch is. They are not asking anybody to install anything. The protocol is the same, the validation is the same, and a client that understands lifetime-proportional renewal handles it without noticing. The entire change reduces to a CA issuing certificates with a shorter validity period and trusting the ecosystem to cope. That is a well-run certificate authority.
The bit I would push back on is the confidence that ARI means everybody is fine. ARI lets the CA pull a renewal forward. It does not let the CA push your renewal back, and every major client deliberately gives a pinned schedule the final word so operators keep control. That is correct behaviour, and it means the responsibility sits with whoever wrote the number in the cron entry. The ecosystem is not going to fix your config for you.
So do the unglamorous thing. Five greps, one staging rehearsal, and delete the offsets. Nobody will ever compliment you for it. Your monitoring will be quiet, your renewal logs will be boring, and in February you will still have working certificates while somebody else explains to a client why their Sunday morning is gone.
Mathew Clark Founder, SecureInSeconds Currently: deleting three renewal offsets that were older than my eldest kid's laptop Drafted with AI assistance - read, verified, and fixed by a human.
Further Reading
- 64-Day Certificates Are Coming (Let's Encrypt, 7 October 2026)
- Let's Encrypt Staging Environment documentation
- RFC 9773: Support for ACME Renewal Information (ARI)
- Certbot 4.1.0 release notes - ARI support added 10 June 2025
- acme.sh 3.1.4 release notes - ARI support added 17 July 2026
- Caddy 2.8.0 release notes - ACME Renewal Information support, 29 May 2024
- Android 17 and certificate transparency: what changes for internal CAs
- ServiceNow: patch your self-hosted AI Platform this week
