Skip to main content
Server & DevOpsOctober 19, 20262 min read

Let's Encrypt Moves to 64-Day Certificates in February

Get technical support

Patched, monitored, restored on a schedule

From February 10, 2027, Let's Encrypt issues 64-day certificates by default, and its staging environment already switched on October 14. Automated renewals keep working, but scripts with a hardcoded 60, 80 or 83 days need a look.

What Changes, and When

Let's Encrypt announced on October 7 that any certificate it issues or renews on or after February 10, 2027 will be valid for 64 days instead of 90. Nothing is revoked as part of the change. Certificates issued before that date keep their 90 days, and Let's Encrypt expects the last of them to expire on May 11, 2027.

The staging environment started issuing 64-day certificates on October 14, 2026, so the new lifetime can be tested today without touching production.

Shorter lifetimes are already available for anyone who wants them, 45 days or 6 days through certificate profiles. The 64-day default is a step on the way to a 45-day default in 2028.

Who Needs to Do Anything

If your ACME client supports ACME Renewal Info (ARI), Let's Encrypt tells it when to renew, and the shorter lifetime needs no work. Clients that renew a fixed number of days before expiry, such as certbot with its default of 30 days, also keep working, because they count back from the expiry date.

The setups that break are the ones that count forward from the issue date. Let's Encrypt suggests grepping cron jobs, wrapper scripts and runbooks for numbers like 83, 80 or 60. A job that renews 80 days after issuance would now run 16 days after the certificate expired. One that renews at day 60 leaves a four-day margin, which is gone the first time a renewal fails over a weekend.

The recommended fix is to renew at about two thirds of the certificate's lifetime, which for 64 days is roughly day 43. These commands find the usual suspects and show when a certificate actually expires.

grep -rnE "\b(60|80|83)\b" /etc/cron* /etc/systemd/system 2>/dev/null | grep -iE "cert|acme|renew"
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -noout -enddate

Authorization Reuse Gets Shorter Too

A second change is easy to miss. Today a validated domain can be reused for 30 days before Let's Encrypt asks for a new challenge. That window will drop to 10 days, and in 2028 to seven hours. Let's Encrypt says no changes are needed unless your client relies on reusing an earlier validation.

What Stays the Same

Rate limits are not affected. ACME endpoints and certificate chains do not change either, so no client needs a new URL.

What We Would Check First

Run one renewal against staging with the same client you use in production, then read the expiry date on the certificate it returns. Make sure whatever serves the certificate reloads it on its own after renewal, and that a failed renewal raises an alert somewhere a person will see it. Let's Encrypt recommends automating both.

If you are also weighing other free certificate authorities, our look at whether your ACME client works with Cloudflare's new free CA covers the same clients from a different angle. Certificate automation across a fleet is part of our server management work.

Sources: Let's Encrypt, 64-day certificates

Or read how we handle it in Servers Management.