Let’s Encrypt Goes to 64-Day Certs on Feb 10: Fix Your Cron Now

On February 10, 2027, Let’s Encrypt will start issuing certificates that expire in 64 days instead of 90. That is 97 days from today. If your renewal automation runs every 60 days, you now have a 4-day buffer before your site presents an expired certificate. If that renewal hits a DNS provider outage, a silent script failure, or a misconfigured firewall rule during those four days, your buffer disappears. The organizations that will feel this hardest are not the ones using Caddy or acme.sh — those already handle it. The ones at risk are running a cron job nobody has touched since 2021.

What Changed, and Why It Won’t Change Back

The Internet Security Research Group (ISRG), which runs Let’s Encrypt, announced the reduction in October 2026. Staging already switched on October 14, so if you’re testing against the staging environment, you’re already seeing 64-day certs.

The roadmap does not stop at 64 days. The CA/Browser Forum’s Ballot SC-081 sets legally binding maximums for all publicly trusted certificate authorities:

• February 10, 2027 — Let’s Encrypt default: 90 days → 64 days
• February 16, 2028 — Let’s Encrypt default: 64 days → 45 days
• March 2029 — Industry maximum: 47 days (affects all public CAs)

The underlying reason is that certificate revocation — OCSP and CRL — does not reliably work at scale. Browsers increasingly skip revocation checks for performance. As Scott Helme notes, shorter lifetimes are not a supplement to revocation; they are the replacement. A cert that expires in 64 days is compromised for at most 64 days. That is the fix.

The Math That Should Worry You

The problem is not 64-day certificates. The problem is renewal automation calibrated for 90-day certificates.

Certificate Lifetime	60-Day Renewal Schedule	Remaining Buffer
Current: 90 days	Renews on day 60	30 days — fine
Feb 2027: 64 days	Renews on day 60	4 days — dangerous
2028: 45 days	Renews on day 60	Certificate already expired

The 2028 row is not hypothetical. If you do not fix your renewal setup before February 2027, the 45-day transition in 2028 will break you completely.

Find Out If You’re Exposed

Search your infrastructure for hardcoded renewal values calibrated for 90-day certificates. The common offenders are 60, 80, and 83:

grep -rnw -E '60|80|83' /etc/cron* /etc/cron.d /var/spool/cron 2>/dev/null | grep -i cert

For Kubernetes users, audit your cert-manager certificates:

kubectl get certificates -A

Check a live certificate’s remaining validity directly — the cron job exit code tells you nothing:

openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates

Where Your ACME Client Stands

ACME Renewal Information (RFC 9773, ARI) is the permanent fix. With ARI, the certificate authority tells your client the optimal renewal window — no hardcoded schedules, no math required. Here is what you’re working with today:

Client	Safe for 64-Day Certs?	Action Required
Caddy	Yes	None — ARI-aware by default
acme.sh 3.1.4+	Yes	None — ARI support since July 2026
certbot (systemd timer, twice daily)	Yes	Verify timer is running (see below)
certbot (manual 60-day cron)	No	Switch to systemd timer immediately
cert-manager (default config)	Risky	Enable ACMEUseARI feature gate or fix renewBefore

cert-manager deserves extra attention. ARI support landed in cert-manager 1.21 as an Alpha feature behind the ACMEUseARI feature gate, disabled by default. A loop bug in that implementation was fixed in October 2026. If you are on cert-manager and have not explicitly enabled ARI or switched from fixed renewBefore values to percentage-based windows, you are running with 90-day assumptions.

The Fix: Three Steps

If you’re using certbot on a modern Debian or Ubuntu system, the right approach is the systemd timer — not a cron job. The timer runs twice daily with randomized jitter and lets certbot decide when to renew:

# Enable and start the certbot timer
sudo systemctl enable --now certbot.timer

# Verify it's active
systemctl status certbot.timer

# Simulate a renewal to confirm it works
sudo certbot renew --dry-run

Then fix your monitoring. Alert on the actual certificate expiry, not on whether the renewal script ran. A common threshold is 14 days remaining:

# Returns exit code 1 if cert expires within 14 days (1209600 seconds)
openssl s_client -connect yourdomain.com:443 2>/dev/null \
  | openssl x509 -noout -checkend 1209600 \
  || echo "ALERT: Certificate expires in under 14 days"

Automate Now, Then Forget It

The frustrating part of this change is that it asks nothing complicated. Sarah Gran of ISRG said it plainly: “If your renewals are automated and your client supports ARI, you should be all set.” That is the entire ask.

The organizations that will have outages in February 2027 are the ones that set up a cron job in 2021, confirmed it worked, and never looked again. 97 days is enough time to audit your setup, switch to a timer, enable ARI where it’s available, and add real certificate monitoring. Do it now. By 2028, when 45-day certs arrive, it’s already handled.