Let’s Encrypt has announced that certificates will last 64 days from February 10, 2027, then 45 days from February 2028. The rest of the web PKI is moving the same way. Automated renewals that worked for years with 90-day certificates can fail quietly with shorter ones, and the first sign is often an expired-certificate error in a browser.

Here is how to find every certificate you depend on and make sure each one renews in time.

Step 1: inventory your certificates

Start with what each server is actually presenting:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -enddate

Then find certificates on disk:

sudo certbot certificates 2>/dev/null
sudo find /etc /opt /srv -name '*.pem' -path '*live*' 2>/dev/null
ls ~/.acme.sh 2>/dev/null

Don’t forget certificates outside web servers: mail servers (Postfix, Dovecot), reverse proxies, load balancers, VPN endpoints, MQTT brokers, and anything embedded in Docker volumes.

Step 2: find every renewal mechanism

systemctl list-timers | grep -iE 'cert|acme|lego'
sudo crontab -l; crontab -l
ls /etc/cron.d/ /etc/cron.daily/ | grep -iE 'cert|acme'
docker ps --format '{{.Names}} {{.Image}}' | grep -iE 'caddy|traefik|certbot|acme|nginx-proxy'

For each one, answer two questions: how often does it run, and how does it decide to renew?

Step 3: check each client

Client	How it decides	What to check
certbot	Renews within 30 days of expiry by default	certbot renew runs at least daily via its timer or cron; no hard-coded day counts in wrapper scripts
Caddy	Manages renewal itself, supports ARI	Keep Caddy current; nothing else to do
Traefik	Renews ahead of expiry automatically	Keep it current and check its logs for ACME errors
acme.sh	Has its own renewal interval setting	Check the per-domain renewal days in its config and that its cron runs daily
Custom scripts	Whatever you wrote	The usual culprit

The dangerous pattern is a fixed schedule: a cron job that requests a new certificate every 60 days, or a script that checks for “fewer than 30 days remaining” but only runs weekly. Let’s Encrypt specifically suggests searching scripts for the numbers 83, 80, and 60:

sudo grep -rnE '\b(83|80|60)\b' /etc/cron* /usr/local/bin /opt/*/renew* 2>/dev/null | grep -iE 'day|renew|cert'

The fix is almost always to run the client’s own renewal logic, such as certbot renew, daily, and let it decide. Our systemd timers guide shows how to schedule it reliably.

ACME Renewal Information

ARI lets the certificate authority tell each client exactly when to renew. A client that supports it adapts automatically when lifetimes change, and can renew early if the CA needs to revoke certificates after an incident. Prefer clients that support ARI; recent versions of the major ACME clients do, but check your version’s documentation.

Step 4: test against staging

Let’s Encrypt’s staging environment issues 64-day certificates already. With certbot:

sudo certbot certonly --staging -d test.example.com --webroot -w /var/www/html
sudo certbot renew --dry-run

Staging certificates are not trusted by browsers, so use a test domain. The point is to confirm your renewal pipeline, deploy hooks, and service reloads all work end to end.

Step 5: reload after renewal

A renewed certificate on disk does nothing until the service loads it. certbot’s deploy hooks handle this:

sudo certbot renew --deploy-hook 'systemctl reload nginx'

Or place a script in /etc/letsencrypt/renewal-hooks/deploy/. Services that cache certificates in memory, such as some mail servers and Java applications, need a reload or restart too. With shorter lifetimes, a missed reload causes an outage sooner.

Step 6: monitor from the outside

Renewal can fail for reasons your server cannot see: DNS changes, firewall rules blocking validation, rate limits. Check certificates externally and alert well before expiry:

• Uptime Kuma and Gatus can alert on certificate expiry
• A Prometheus blackbox exporter exposes probe_ssl_earliest_cert_expiry
• Make renewal jobs report failures by email or a notification service

Alert when fewer than about 14 days remain. With a 64-day certificate renewed at day 42, that still leaves days to react.

Summary

1. List every certificate and every renewal mechanism
2. Make renewal run daily and let the client decide when to renew
3. Remove fixed intervals of 60 days or more
4. Test with staging, including the reload step
5. Monitor expiry from outside

Our Let’s Encrypt guide covers certbot setup from scratch, and our reverse proxy guide covers servers like Caddy that handle certificates for you.

Frequently Asked Questions

When do Let’s Encrypt certificates become 64 days?

For certificates issued or renewed on or after February 10, 2027. Existing 90-day certificates are not revoked and run until they expire, with the last ones expiring around May 2027. A further move to 45 days is planned for February 2028.

Will certbot handle shorter certificates automatically?

Usually yes. certbot renew renews certificates that are within 30 days of expiry by default, so a 64-day certificate renews at around day 34. Problems come from custom scripts or cron jobs that renew on a fixed schedule rather than running certbot renew regularly.

What is ACME Renewal Information?

ARI is an ACME extension where the certificate authority tells the client when to renew each certificate. Clients that support it adapt automatically to new lifetimes, and the CA can ask for early renewal if a certificate needs to be revoked.

What renewal schedule is safe for 64-day certificates?

Let’s Encrypt recommends renewing at about two-thirds of the lifetime, roughly day 42 for a 64-day certificate, and running the renewal check at least daily. Any job that renews every 60 days or more is too slow.

How can I test with 64-day certificates now?

Let’s Encrypt’s staging environment has issued 64-day certificates since October 14, 2026. Point your ACME client at the staging directory URL, issue a certificate for a test domain, and confirm your renewal process handles it.

How do I get alerted before a certificate expires?

Use external monitoring that checks the certificate your server actually presents, such as Uptime Kuma, Gatus, or a Prometheus blackbox exporter probe, and alert when fewer than about 14 days remain. Also make renewal failures send an email or notification.