Big change ahead for every website using free SSL: Let’s Encrypt 64-day certificates become the default on February 10, 2027. Announced on October 7, 2026, the move cuts the default certificate lifetime from 90 days to 64 days – the next step on the road to 45-day certificates in 2028.

If your renewals are fully automated, you are probably fine. If anything in your setup assumes “90 days”, it’s time to fix it. Here’s a practical checklist.

What Is Changing?

• From February 10, 2027, every certificate issued or renewed by Let’s Encrypt will be valid for 64 days by default.
• Subscribers who already chose shorter lifetimes (45-day or 6-day certificates) are not affected.
• Existing 90-day certificates will not be revoked. The last 90-day certificates are expected to expire around May 11, 2027.
• 64-day certificates have been available in the staging environment since October 14, 2026, so you can test today.
• Rate limits, ACME endpoints and certificate chains do not change.

The Road to 45 Days

Date	Change
2026	Authorization reuse cut from 30 days to 10 days
Feb 10, 2027	Default lifetime 90 → 64 days
2028	Default lifetime 64 → 45 days; authorization reuse drops to 7 hours

These changes follow the CA/Browser Forum’s industry-wide plan to shorten certificate lifetimes and reduce the impact of compromised keys.

Step 1: Find Hard-Coded Renewal Schedules

The biggest risk is scripts that assume a 90-day lifetime – for example “renew when 30 days are left” or “renew every 60 days”. Search your servers and repos:

# Look for hard-coded day values in cron, scripts and runbooks
sudo grep -rnE "\b(60|80|83|89|90)\b" /etc/cron* /etc/letsencrypt/renewal-hooks /usr/local/bin 2>/dev/null
grep -rnE "days.*(60|80|90)|renew.*(60|80|90)" ./infra ./scripts 2>/dev/null

Let’s Encrypt recommends renewing at roughly two-thirds of the certificate lifetime. For a 64-day certificate, that’s around day 42–43.

Step 2: Use ACME Renewal Information (ARI)

ARI lets the CA tell your client when to renew. Clients that support ARI need no changes. Recent versions of Certbot, lego, acme.sh, Caddy and Traefik support it – update your client to the latest version:

certbot --version
sudo apt install --only-upgrade certbot   # or: sudo snap refresh certbot

# Dry-run renewal against staging
sudo certbot renew --dry-run

Step 3: Test 64-Day Certificates in Staging

sudo certbot certonly --staging -d example.com --dry-run

For other clients, point them to the staging directory URL: https://acme-staging-v02.api.letsencrypt.org/directory.

Step 4: Automate Reload and Deployment

A renewed certificate on disk is useless if Nginx or HAProxy keep serving the old one. Add a deploy hook:

# /etc/letsencrypt/renewal-hooks/deploy/reload.sh
#!/bin/sh
systemctl reload nginx

Also remember certificates copied to load balancers, CDNs, Kubernetes secrets or Java keystores – those copy steps must be automated too.

Step 5: Monitor Expiry and Alert on Failures

# Days until expiry for a live site
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

Set alerts when a certificate has less than about 20 days remaining. With 64-day certificates, a renewal failure leaves you much less time to react.

Quick Checklist

• Update your ACME client to a version with ARI support.
• Remove hard-coded 60/80/90-day assumptions.
• Test with the staging environment.
• Automate service reloads and certificate distribution.
• Monitor expiry and alert on failed renewals.

Conclusion

Let’s Encrypt 64-day certificates are a small change for fully automated setups and a real outage risk for anything manual. Spend an hour now auditing your renewal pipeline and you’ll be ready for February 2027 – and for 45-day certificates in 2028.