Let's Encrypt Goes to 64 Days on February 10. Your Hardcoded 60s and 80s Are Already Wrong.

February 10 is not opt-in

Somewhere on one of your servers there is a number. Maybe 60, maybe 80, maybe 83. Somebody typed it years ago, when Let's Encrypt certificates lasted 90 days. On February 10, 2027, it stops being right.

Let's Encrypt announced on October 7 that every certificate it issues or renews from that date gets a 64-day lifetime by default. You don't opt in. The default classic profile changes underneath you, and unless you already picked something shorter (the 45-day tlsserver profile or the six-day shortlived one), 64 days is what you get.

The rest of the announcement, roughly in the order it will hurt:

• Staging switches to 64-day certificates on October 14, 2026. That's this week.
• The last 90-day certificate should expire on May 11, 2027.
• Nothing gets revoked. Your current certs run out their full 90 days.
• Authorization reuse drops from 30 days to 10, and to seven hours in 2028.
• Rate limits, ACME endpoints and issuance chains stay as they are.

This is step one of the plan Let's Encrypt published in December 2025. Step two, on February 16, 2028, is 45-day certificates and seven-hour reuse. The industry-wide schedule behind it is in our post on the CA/Browser Forum's 47-day timeline. This post is about the numbers in your config that break in February.

Run the arithmetic on your own numbers

Let's Encrypt tells you to renew at about two-thirds of a certificate's lifetime. For a 90-day cert that's day 60. For a 64-day cert it's around day 43, with roughly 21 days still on the clock.

Now try the numbers people actually hardcode:

Look at the last two rows. Anything that counts backwards from notAfter survives, because its anchor moves with the certificate. Anything that counts forward from the issue date, or runs off a calendar, doesn't.

The two-month cron is the worst, because it looks fine. The next run comes 59 to 62 days after the last, on a cert that lives 64. A few days of margin, and if that run fails, the next attempt is two months away. That's a coin flip with your production TLS.

Let's Encrypt's own advice is blunt: "Grep for common hardcoded numbers like 83, 80 or 60 in cron jobs, wrapper scripts and runbooks." So grep.

Where those numbers hide

Start wide. This catches most wrapper scripts and cron entries:

grep -rnE '\b(60|80|83)\b' /etc/cron* /etc/systemd/system /usr/local/bin /opt 2>/dev/null \
  | grep -iE 'cert|acme|renew|ssl|tls|days'

You'll get noise. A 60 next to --days or -mtime is the one you care about. Then check each client, because each keeps the number somewhere different.

certbot

Since certbot 4.0 the default is to renew when a third of the lifetime is left, which is about day 43 on a 64-day cert. Certbot 4.1 added ARI, and an early ARI answer beats a later renew_before_expiry. Older distro packages renew 30 days before expiry, so day 34. Plain certbot renew on a timer is fine. What people bolt onto it isn't:

grep -H renew_before_expiry /etc/letsencrypt/renewal/*.conf
grep -rn -- '--force-renewal' /etc/cron* /etc/systemd/system 2>/dev/null

A --force-renewal on a fixed calendar is that two-month cron from the table. Delete it.

acme.sh

No client changed more this year, so check your version before anything else.

Up to 3.1.2, acme.sh renewed 60 days after issuance by default. Day 59, really, since it subtracts a day. On a 64-day cert that leaves five. Version 3.1.3 lowered the default to 30. Version 3.1.4, out July 17, 2026, switched ARI on by default and capped a fixed --days so it can never schedule renewal after expiry. Before that, --days 80 on a 64-day cert would just watch it lapse.

Then 3.1.5 let an explicit --days outrank the ARI window: the CA can still pull a renewal earlier, never push one later. Reasonable. It also means the --days 60 you typed in 2023 is now a pinned schedule, and the client treats it as one. Find out which certs carry it:

acme.sh --version
grep -H Le_RenewalDays ~/.acme.sh/*/*.conf
acme.sh --list

Le_RenewalDays only shows up in a domain's conf if someone passed --days. The Renew column in acme.sh --list is the date the client will actually act on.

cert-manager

cert-manager works out renewal from the certificate it actually got back, whatever spec.duration asked for. No renewBefore set? It renews two-thirds of the way in. Done.

A renewBefore tuned for 90-day certs is the trap. As long as the value is shorter than the real lifetime, cert-manager follows it to the letter. renewBefore: 1440h (60 days) on a 64-day cert means a renewal four days after every issuance. Forever. cert-manager only ignores renewBefore and falls back to two-thirds when the value is longer than the whole lifetime.

kubectl get certificates -A \
  -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,RENEW_BEFORE:.spec.renewBefore,PCT:.spec.renewBeforePercentage

If you want a setting that survives the next lifetime cut too, use a percentage:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-example-com
spec:
  secretName: api-example-com-tls
  dnsNames:
    - api.example.com
  renewBeforePercentage: 33
  issuerRef:
    name: letsencrypt
    kind: ClusterIssuer

On cert-manager 1.21, ARI is still behind a feature gate. Turning it on has a few sharp edges.

Caddy and Traefik

Caddy renews with a third of the lifetime left and speaks ARI. Nothing to do. Traefik's default certificatesDuration of 2160 hours makes it renew 30 days before expiry, so day 34 on a 64-day cert. Also fine, unless someone changed it.

Staging switches this week, so use it

From October 14, Let's Encrypt staging issues 64-day certificates. It's the only place to get one before February. As a commenter on Hacker News pointed out, no production profile issues 64-day certs early. The closest is the 45-day tlsserver profile: survive 45 days and you'll survive 64. It also drops the Key Encipherment key usage, though, so read the profile docs before you point production at it.

Getting a staging certificate proves almost nothing. You want to know when your client plans to renew it. Issue a throwaway cert on a real host:

# certbot, in a separate lineage so production is untouched
certbot certonly --staging --cert-name le64-test \
  --webroot -w /var/www/html -d le64-test.example.com

# acme.sh
acme.sh --issue --server letsencrypt_test \
  -d le64-test.example.com -w /var/www/html

Read the dates off the certificate and compare them with what your tooling intends to do:

cert=/etc/letsencrypt/live/le64-test/cert.pem
start=$(date -d "$(openssl x509 -in "$cert" -noout -startdate | cut -d= -f2)" +%s)
end=$(date -d "$(openssl x509 -in "$cert" -noout -enddate | cut -d= -f2)" +%s)
echo "lifetime: $(( (end - start) / 86400 )) days"
echo "two-thirds mark: $(date -u -d @$(( start + (end - start) * 2 / 3 )) +%F)"

On Kubernetes, point a test Certificate at a staging ClusterIssuer and read .status.notAfter and .status.renewalTime. Renewal time after the two-thirds mark, or after notAfter? You just found your February incident four months early.

Your 30-day expiry alert is about to cry wolf

Most teams will notice this one first.

The classic "expires in less than 30 days" warning grew up around 90-day certs that renew on day 60. Alert and renewal line up exactly, so a healthy cert never trips it.

On a 64-day cert, 30 days remaining means day 34. The healthy renewal comes around day 43. So every Let's Encrypt certificate you own will trip the 30-day warning about nine days before it's even due. Nothing is wrong. Your dashboard goes yellow anyway, every cycle, and people stop looking. We've written about where alert fatigue takes a team, and this is a shortcut there.

Change the thresholds before February. Waiting for the first wave of false alarms is how the habit of ignoring them starts.

• Warn at 14 days remaining. A 64-day cert renewed on schedule never gets that low.
• Page at 7 days. By then the cert has been sitting in its renewal window for two weeks.
• On ARI-aware clients, alert on missed renewals. A cert that's past its ARI window and still hasn't been replaced is your real signal. The ARI post explains why.

Between February and May 2027 your fleet carries 90-day and 64-day certs side by side. A percentage of lifetime left works for both. A fixed day count doesn't.

Authorization reuse drops to 10 days

The quieter half of the announcement. Right now, once you prove control of a domain, Let's Encrypt reuses that authorization for 30 days. From February 10, it's 10. In 2028 it's seven hours, which in practice means every order validates from scratch.

Let's Encrypt says nothing changes unless your client was designed around reuse. The setups that were are usually home-grown:

• One manual DNS-01 run with certbot --manual, then more certificates for the same names over the following weeks.
• Several servers on one ACME account, where only the first can answer a challenge and the rest have been quietly riding its authorization.
• A pipeline that validates in one job and finalizes the order in another, days later.

Ten days is where those start failing. Seven hours kills them. Every host that requests a certificate has to be able to finish a challenge on its own. If DNS-01 is your only route, start with why DNS-01 validation keeps breaking.

The certificates you can't grep

Everything above assumes you can open the box. Plenty of Let's Encrypt certs live on things you can't: a NAS with a built-in ACME toggle, a firewall, an appliance a contractor set up in 2021. They have renewal logic too. You just can't read it.

You can still find them. Every Let's Encrypt certificate goes into the Certificate Transparency logs, so a search for your domains on a CT search tool like crt.sh lists what has actually been issued, whatever requested it. Compare it with the hosts your own clients manage. Whatever is left over has renewal logic you've never seen. Our CT log explainer covers how that search works.

Check the vendor's release notes for ARI or shorter lifetimes. If there's nothing, put an external expiry check on the hostname at 14 days. The device won't warn you. It'll just stop renewing on a Saturday.

Frequently asked questions

Will Let's Encrypt revoke my existing 90-day certificates on February 10, 2027? No. Let's Encrypt has said explicitly that it won't revoke valid certificates as part of this change. Certificates issued before February 10 keep their 90-day lifetime, and the last of them should expire around May 11, 2027.

Can I get a 64-day certificate in production before February? No. None of the current production profiles issues 64-day certificates. Staging does from October 14, 2026, and in production the 45-day tlsserver profile is the closest stricter test, although it differs in other ways, such as dropping the Key Encipherment key usage.

Does the change affect Let's Encrypt rate limits? Let's Encrypt says rate limits are not affected. You will place more orders per year, so if a large fleet already runs close to a limit on one account, check your headroom anyway.

My ACME client supports ARI. Do I still need to do anything? For the renewal itself, mostly not, since ARI lets Let's Encrypt tell the client when to renew. Still check for pinned values such as an acme.sh --days or a cert-manager renewBefore, and still move your expiry alert thresholds, because ARI does nothing for a monitor that counts days remaining.

What happens in 2028? On February 16, 2028, the default classic profile moves to 45-day certificates and authorization reuse drops to seven hours. If you renew at two-thirds of the lifetime and avoid fixed day counts, you won't need to touch your configuration again for that step.