Let's Encrypt switches its default profile to 64-day certificates on February 10, 2027, and 45-day certs follow in 2028. If your renewals still run on a calendar reminder, consider this your wake-up call.

For a decade, Let's Encrypt certificates lived 90 days and renewals ran every 60 — a rhythm every sysadmin internalized. That rhythm is ending. The CA's announced timeline is explicit: the opt-in tlsserver ACME profile already issues 45-day certificates (since May 13, 2026, for testing), the default classic profile drops to 64 days on February 10, 2027, and full 45-day issuance with a 7-hour authorization reuse period arrives February 16, 2028. This isn't a Let's Encrypt quirk, either: the CA/Browser Forum's baseline requirements push all publicly trusted CAs toward a 47-day maximum by March 2029. The whole industry is compressing.

If your certificate automation is solid, you may feel nothing. If any part of your infrastructure renews by hand — a calendar reminder, an SSH session, a copied-and-pasted TXT record — those workflows are on a deadline. Four months out from the first cutover is exactly when to build the playbook.

Why shorter is better (the part worth agreeing with)

Shorter certificate lifetimes shrink the blast radius of a compromised key. A stolen private key is useful only until the certificate expires, so moving from 90 to 64 to 45 days cuts that window meaningfully. It also makes revocation — historically the weakest link in web PKI — less critical, because expiry does the revocation's job automatically. This is the same logic that has driven every validity reduction since the 398-day era. It is not going back.

The renewal playbook

1. Inventory everything. List every TLS certificate you own and how each renews: which ACME client, which challenge type (HTTP-01, DNS-01, TLS-ALPN-01), which automation, and who gets paged when it fails. The certs you forget — the staging box, the internal dashboard, the mail server — are the ones that will bite you at 64 days.

2. Stop renewing on a fixed schedule. The classic "renew 60 days in" cron job breaks under shorter lifetimes. Let's Encrypt's guidance: use ACME Renewal Information (ARI), which tells the client exactly when to renew based on the CA's current state. For clients without ARI support, renew roughly two-thirds of the way through the certificate's lifetime — about day 43 for a 64-day cert, day 30 for a 45-day one — not at fixed intervals.

3. Audit your ACME client. Older clients may assume 90-day validity or mishandle ARI responses. Update certbot, acme.sh, lego, or whatever you run, and verify it supports the tlsserver profile now so you can opt in early and catch edge cases on your own schedule.

4. Watch the authorization reuse shrink. Domain-validation reuse drops from 30 days to 10 days in February 2027, then 7 hours in 2028. If your automation depends on cached validations — common with DNS-01 setups — it will start revalidating far more often. Watch for DNS-PERSIST-01, the new challenge type in development that uses a static TXT record across renewals, designed precisely to simplify this.

5. Add expiry monitoring now. Even with perfect automation, renewal failures happen — DNS hiccups, firewall changes, a CA-side outage. Monitoring that alerts at, say, 21 days before expiry gives you time to intervene. At 64-day lifetimes, "I'll notice in the browser" stops being a plan.

6. Test with the tlsserver profile. You don't have to wait for February. Opt into the 45-day profile on a non-critical domain today and watch your pipeline handle the compressed cadence. Anything that wobbles at 45 days was already fragile at 90 — you just never saw it.

The operator's takeaway

The shift to 64-day and then 45-day certificates is not a crisis; it is the industry finishing a transition it announced years ago. But it is the final nail in the coffin for manual certificate management. Build the inventory, fix the renewal timing, turn on monitoring — and do it while you still have four months, not during an outage.

Sources