Why your ACME renewal quietly broke last month

Let's Encrypt changed its intermediates, dropped an EKU, killed OCSP, and started shortening lifetimes. None of it throws a renewal error. Here is what to check.

The honest version of the headline is that it probably did not break in a single month. Let’s Encrypt has been executing a long, well-published sequence of changes since late 2024, and the ones that hurt share a property: the renewal itself succeeds. Your cron job exits zero, your monitoring sees plenty of runway on the expiry date, and something else — a client, a peer, a stapling directive — fails where you are not looking.

The safety net was removed first

Let’s Encrypt stopped sending certificate expiration emails on 4 June 2025, and said so in January of that year. The reasoning was sound — automation has matured, storing millions of email addresses against certificate records is a privacy liability, and the service cost tens of thousands of dollars a year.

The consequence is that the last human-readable warning that renewal had stopped working is gone. If your only expiry monitoring was “Let’s Encrypt will email me”, you have had no monitoring for over a year.

The client-authentication EKU disappeared

This is the quietest failure in the set.

Let’s Encrypt announced in May 2025 that it would drop the TLS Web Client Authentication EKU, ahead of Chrome’s root-program requirement to separate client and server authentication into distinct PKIs. The schedule ran: 11 February 2026, the default classic profile stopped including the EKU; 8 July 2026, the tlsclient profile was removed entirely and no further certificates with the EKU are issued.

If you were using a public Let’s Encrypt certificate as an mTLS client credential — a service-to-service call, a webhook signer, a database client cert — the renewal worked fine and the certificate is valid. It just no longer asserts a purpose the peer requires, so the peer rejects it during handshake. The error surfaces on the other side of the connection, in someone else’s logs, as a generic handshake failure.

Check with:

openssl x509 -in cert.pem -noout -ext extendedKeyUsage

If you need client auth, that is a private-CA job now. It always was.

The chain moved

In a September 2025 key ceremony Let’s Encrypt generated a new root and intermediate hierarchy, announced that November. The four intermediates now in active rotation are YE1 and YE2 (ECDSA P-384) and YR1 and YR2 (RSA 2048), all valid to 2028-09-02, per the active certificates page. ISRG Root X1 and X2 remain the trusted production roots; the new ISRG Root YE and YR are not yet in trust stores.

Two things follow. First, each issuance now picks an intermediate at random, deliberately, to discourage intermediate key pinning. If you pinned one — in a Java truststore, an embedded device, or a mobile app’s pin set — renewals will appear to succeed and clients will fail at unpredictable intervals as the selection cycles. Second, anything that hardcoded a chain file instead of deploying the fullchain.pem your client produced is now serving a stale chain.

OCSP is gone, and your config still asks for it

Let’s Encrypt published the OCSP wind-down schedule in December 2024: Must-Staple issuance stopped on 30 January 2025, OCSP URLs were removed from certificates on 7 May 2025, and the responders were switched off on 6 August 2025. Revocation is now published exclusively via CRLs.

The shutdown was sequenced so nothing broke on the day — every certificate containing an OCSP URL had already expired. What lingers is configuration. An nginx block with ssl_stapling on; against a certificate with no OCSP URI cannot staple anything, logs a warning on every reload, and adds a pointless resolver dependency. Turn it off.

Lifetimes are on a published downward schedule

Two independent clocks are running here, and people routinely conflate them.

The CA/Browser Forum clock: under ballot SC081v3, the maximum validity for any publicly-trusted certificate dropped to 200 days on 15 March 2026, then 100 days in March 2027 and 47 days in March 2029.

The Let’s Encrypt clock, published in December 2025: the opt-in tlsserver profile moved to 45-day certificates on 13 May 2026. The default classic profile is still 90 days today, goes to 64 days on 10 February 2027, and reaches 45 days on 16 February 2028. Separately, 160-hour short-lived certificates and IP-address certificates went generally available on 15 January 2026 under the shortlived profile.

Nothing here breaks today. What it does is punish any renewal process with a manual step in it. A quarterly change window works for 90-day certificates and not for 45-day ones.

What to actually do

Turn on ARI. ACME Renewal Information became RFC 9773 in June 2025. It lets the CA tell your client when to renew, which matters enormously during an incident — when Let’s Encrypt needs to move subscribers off a batch of certificates early, ARI is the mechanism that does it without a manual scramble. Certbot added ARI support in 4.1.0 (10 June 2025); Caddy has had it since 2.8.0. Check your client actually has it enabled rather than assuming.

Monitor the served certificate, not the renewal exit code. Every failure above passes a certbot renew check. Connect to port 443 from outside and alert on the chain and the EKU, not just the expiry date.

Test a real renewal, not a dry run. certbot renew --dry-run exercises the ACME flow, not your deploy hook. The step that rots is the reload.

Stop pinning anything below the root. Intermediates rotate now, on purpose.

The underlying protocol has not changed — RFC 8555 is stable and your client speaks it correctly. Everything that broke this year was policy moving underneath a working protocol, which is exactly the class of change that does not produce an error message.

Read next

• How to read a TLS certificate
• Certificate Transparency explained for devs
• Try the tool: TLS certificate inspector

Tags: #acme, #lets-encrypt, #tls, #sre