Let's Encrypt Suspends All Certificate Issuance for 2.5 Hours After Cross-Signed Root Certificate Flaw Triggers Emergency Rollback
Let's Encrypt, the world's most widely used certificate authority providing free TLS certificates to an estimated 63% of all TLS-enabled websites globally, temporarily suspended all certificate issuance on May 8, 2026, after engineers identified a critical issue involving a cross-signed certificate designed to bridge the organisation's existing Generation X root infrastructure with its upcoming Generation Y root. The complete shutdown — which affected both production and staging ACME API endpoints, as well as both high-assurance datacenter environments — lasted approximately two hours and twenty-eight minutes before services were restored at around 21:03 UTC via a rollback to the Generation X root for the tlsserver and shortlived ACME certificate profiles.
At 18:37 UTC on May 8, Let's Encrypt engineers opened an incident and immediately halted all certificate issuance as a precautionary measure. The cause, as confirmed on the status page after restoration, was a flaw in the cross-signed certificate linking the Generation X root to the new Generation Y root. Cross-signing is a standard and necessary practice in public key infrastructure transitions — when a new root certificate is introduced, older systems that have not yet updated their trust stores cannot directly validate certificates chaining to the new root. A cross-signature from the existing, already-trusted Generation X root allows those older clients to still validate the chain. The cross-sign is what broke, forcing Let's Encrypt to halt all issuance rather than risk distributing certificates with an unresolvable trust chain issue to any portion of its global user base.
The production ACME directory endpoint at acme-v02.api.letsencrypt.org returned HTTP 503 throughout the outage window, while the staging endpoint remained healthy and returned HTTP 200 — confirming the halt was deliberately targeted at production only. ACME clients including certbot, acme.sh, Caddy, Traefik, and cPanel AutoSSL all returned urn:ietf:params:acme:error:serverInternal errors for the duration of the incident.
The blast radius of the outage extended well beyond self-hosted ACME clients and VPS operators. At 20:46 UTC, DigitalOcean opened its own incident confirming that the Let's Encrypt halt was breaking new certificate issuance for Spaces, Spaces CDN, Load Balancers, and App Platform Custom Domains, while simultaneously causing stuck or delayed creates, forks, and restores on Managed Databases including MongoDB, PostgreSQL, and MySQL instances. DigitalOcean confirmed that affected operations would automatically retry once Let's Encrypt's service was restored — but the cascading impact illustrated clearly that a Let's Encrypt issuance halt is not simply a problem for self-managed web servers. Every managed platform layer that quietly depends on Let's Encrypt for TLS termination is exposed whenever the CA experiences even a brief disruption.
Following the rollback, certificates issued after approximately 21:00 UTC chain via the Generation X root — exactly as they have for years. For the vast majority of website operators, browsers, and TLS clients, nothing has changed in practice. The rollback to Generation X keeps trust working for all clients, at the cost of pausing the Generation Y rollout and the shorter handshake chain and ECDSA root advantages that Generation Y was designed to deliver. The two ACME profiles specifically affected by the rollback are tlsserver and shortlived. Administrators using these profiles should verify that certificates issued or renewed around the May 8 outage window chain correctly to the expected Generation X root.
The certificates most acutely exposed during the outage were those using Let's Encrypt's six-day shortlived profile, which became generally available in January 2026. Because shortlived certificates renew approximately every two and a half days, even a two and a half hour outage consumes a meaningful proportion of the available renewal margin — and a longer outage would have created genuine expiry risk for that population of certificates.
This incident arrives at a particularly instructive moment for the internet's TLS infrastructure. Let's Encrypt has already announced its phased roadmap to reduce the default certificate lifetime from 90 days to 45 days by 2028, with the tlsserver profile scheduled to begin issuing 45-day certificates from May 13, 2026 — just five days after this outage. The security rationale for shorter lifetimes is sound: shorter lifetimes limit the damage window of a key compromise and reinforce automation discipline. The operational trade-off, however, is a shrinking buffer between a CA outage and real certificate expiry risk. A 90-day certificate renewing at day 30 carries 30 days of cushion. A 45-day certificate renewing at day 15 carries 15 days. A 6-day shortlived certificate renewing every 2.5 days carries hours.
When that operational sensitivity is layered onto the reality that approximately 63% of TLS-enabled sites depend on Let's Encrypt as their single certificate authority, the combination creates a systemic fragility that today's two-and-a-half-hour outage only partially tested. Security professionals and administrators who treat this incident as a low-cost rehearsal — and use it to implement certificate expiry monitoring, ACME client retry verification, and a tested fallback to ZeroSSL for time-critical renewals — will be better positioned when a longer or more complex CA disruption eventually occurs.
Verify that any renewal jobs that ran between 18:37 and 21:03 UTC on May 8 have since retried successfully. Confirm that certificates issued around the outage window chain correctly to the Generation X root. Implement or verify certificate expiry monitoring with alert thresholds set well before expiry. Review the renewal cadence of any shortlived profile certificates and assess whether the two-and-a-half-day renewal cycle is operationally sustainable under the organisation's current monitoring posture. For organisations that want a tested fallback CA for time-critical renewals, ZeroSSL remains the most widely used free ACME-compatible alternative — noting that it requires External Account Binding and that CAA DNS records may need updating before a switch will succeed. A full postmortem from Let's Encrypt is expected and should be reviewed once published.