What happened
Let's Encrypt is in the middle of moving to a new "Generation Y" hierarchy of roots and intermediates, part of the industry-wide split of server and client authentication into separate PKIs that Chrome's root program required by June 2026. To keep older clients working during the transition, the new intermediates are cross-signed by the old Generation X roots.
Those cross-signs were issued without an explicit serverAuth EKU. Under the current CA/Browser Forum Baseline Requirements, a subordinate CA certificate used to issue TLS server certificates must carry that EKU explicitly, so the cross-signs were non-compliant the moment they existed. Let's Encrypt did the correct thing, which is also the disruptive thing: stop issuing, revoke the affected cross-signs (X2 and YR signed by X1, YE signed by X2), reissue them correctly, and resume. Issuance was down for roughly two hours and twenty-eight minutes. Existing certificates were unaffected and kept working throughout; leaf certificates were compliant on their own.
For subscribers the symptom was a renewal request that failed with a serverInternal error, most visibly for the tlsserver and shortlived ACME profiles. Most ACME clients retry, so most people never knew. Some did not, and some platforms schedule renewals in narrow windows.
Why it matters if you run public infrastructure
A two-and-a-half-hour outage at a CA that issues a very large share of the world's certificates sounds dramatic and was, in practice, nearly invisible. That is the point worth taking away: a failed renewal is silent. Nothing breaks on the day the renewal fails. The certificate that was supposed to be replaced keeps serving. The failure surfaces weeks later, at expiry, as an outage that looks unrelated to anything that happened in May.
This is getting more likely, not less. Let's Encrypt's short-lived profile issues six-day certificates; the industry maximum falls to 100 days in 2027 and 47 in 2029. Renewals become frequent enough that some of them will always coincide with a CA incident, a DNS validation hiccup, a rate limit or an expired API token in your own pipeline. Retry logic handles most of these. The question is how you find the ones it did not handle before the expiry date does.
What to check this week
- Look at the certificate each public host is serving right now and compare its issuance date against your renewal schedule. A certificate that should have been replaced and was not is a stalled renewal, regardless of what the ACME client's logs say.
- Check renewal logs for May 8 between 18:30 and 21:10 UTC on anything that renews on a fixed schedule rather than opportunistically, especially appliances and platform-managed certificates.
- Make renewal failures loud. An ACME client that fails should page someone or at least post somewhere a human reads. Most default installs log to a file nobody opens.
- Add an external check that does not trust your own pipeline. The pipeline is the thing that failed. Something outside it should be watching what is actually served.
How Attack Surface Scan covers this
Attack Surface Scan's served-certificate probes run against every host on your verified domains, daily or every 6 hours by plan, and record the certificate actually presented on 443 and on the custom ports you add. Stalled-renewal detection compares that against the certificate's lifetime: once a certificate is past the point where an automated renewal should have replaced it and the served certificate has not changed, you get an alert, with weeks of runway instead of a 3 a.m. expiry. Certificate transparency monitoring gives the other half of the picture, since a renewal that did happen shows up there as a new precertificate before it is deployed.