Let’s Encrypt 64-Day Certs: What to Fix Before 2027

Let’s Encrypt published its official 64-day certificate announcement on October 7. Four days from today, October 14, the staging environment switches. Production follows on February 10, 2027. Default certificate lifetimes drop from 90 days to 64, and the domain validation reuse window shrinks from 30 days to 10. If your renewal pipeline depends on a hard-coded interval, it survives next year — and breaks in 2028 when 45-day certs arrive. Here is what to check, what to fix, and how to test before any of this hits production.

Two Dates, Two Changes — Know Both

Most coverage has been calling this the “45-day change.” That framing is wrong and it is causing people to defer action. The 45-day target is 2028. The immediate change is a separate step:

• February 10, 2027: Classic ACME profile (the default for everyone) switches to 64-day certificates. Authorization reuse window drops from 30 days to 10 days.
• February 16, 2028: Same profile moves to 45-day certificates. Authorization reuse window drops to 7 hours.

This distinction matters because a 60-day hard-coded renewal interval works in 2027 — barely, with 4 days of margin — and fails in 2028. Fix it once, correctly, rather than fixing the symptom now and the root cause in 16 months.

The Change Nobody Is Talking About: Authorization Reuse

Certificate lifetime gets all the headlines. The authorization reuse window change is more operationally disruptive.

Today, once Let’s Encrypt validates your domain, you can renew without revalidating for 30 days. In February 2027, that window shrinks to 10 days. In 2028, it drops to 7 hours.

For HTTP-01 challenge users, this is invisible — automation handles it. For wildcard certificate operators using DNS-01 challenge, this means updating a DNS TXT record every 10 days starting in 2027, and every few hours in 2028. That second scenario is only operationally viable with Let’s Encrypt’s DNS-PERSIST-01 challenge, which publishes a standing TXT record once and never requires updating it for renewals. If you manage wildcard certs and haven’t looked at DNS-PERSIST-01 yet, do that before February.

Check Your ACME Client First

ACME Renewal Information (RFC 9773) is the protocol extension that lets Let’s Encrypt tell your client when to renew, rather than relying on your schedule. Clients with ARI support are largely self-managing for this change.

• Certbot 4.1.0+ — ARI support since June 2025. Checks on cron/systemd timer runs. Verify with certbot --version.
• Caddy — Best-in-class ARI implementation. Runs as a long-lived process, polls continuously, sends the replaces field. No configuration needed.
• acme.sh 3.1.4+ — ARI added July 2026. Run acme.sh --upgrade if you haven’t recently.
• Lego v4.16+, win-acme, Certify The Web — All support ARI.
• cert-manager (Kubernetes) — No ARI support. Feature request #6010 has been open since May 2023 with no implementation timeline.

If your client is on the supported list and up to date, verify ARI is active with a dry run:

certbot renew --dry-run -v 2>&1 | grep -i 'ari\|renewal\|window'

The 60-Day Trap

If you manage renewal schedules manually — cron jobs, scripts, runbooks — search for hard-coded values now:

grep -rn "83\|80\|60" /etc/letsencrypt/renewal/ /etc/cron* ~/.acme.sh/ 2>/dev/null

A 60-day renewal interval was the standard advice for 90-day certificates. It survives the 2027 change to 64 days with a 4-day buffer. It will not survive 45-day certificates in 2028. The correct fix is to stop thinking in fixed days and renew at approximately two-thirds of the certificate’s lifetime — for 64-day certs, that is day 42 or earlier.

Fix it now, not in 16 months when you’re diagnosing an outage at 2 AM.

cert-manager: Manual Mitigation Only

Kubernetes operators running cert-manager have no ARI path available. The project’s workaround is to shorten your renewBefore value:

spec:
  renewBefore: 21d  # down from the typical 30d default

This keeps you safe for 64-day certs. When 45-day certs arrive in 2028, drop it to 15 days. It is inelegant, but it is the only option until the ARI feature request is resolved.

Test in Staging Before October Ends

Starting October 14, Let’s Encrypt’s staging environment issues 64-day certificates. Use it. Staging certs are not browser-trusted and will not affect production, but they expose renewal automation bugs before February 2027 does.

certbot certonly --staging --dry-run -d yourdomain.com

If your automation handles staging 64-day certs correctly — and handles the 10-day authorization reuse window — you are prepared for production. You have until February. That is more runway than most infrastructure changes get.

Checklist: What to Do This Week

• Check your ACME client version and confirm ARI support (see list above).
• Grep for hard-coded renewal intervals (83, 80, 60 days) in cron jobs and scripts.
• Update acme.sh if you haven’t recently — ARI arrived in v3.1.4 (July 2026).
• Kubernetes / cert-manager: Adjust renewBefore to 21 days or less.
• Wildcard certs / DNS-01: Evaluate DNS-PERSIST-01 as a long-term solution for the shrinking authorization window.
• Test against staging starting October 14. Fix what breaks before 2027 does.

The full announcement is on the Let’s Encrypt blog. The ACME Renewal Information protocol is specified in RFC 9773.