Let's Encrypt Halted Issuance Over Broken Cross-Sign
Let's Encrypt stopped all certificate issuance on May 8 after a cross-sign flaw in its new Generation Y root. The postmortem reveals missing EKU fields.
On May 8, 2026, at 18:37 UTC, Let’s Encrypt did something it has only done a handful of times in its history: it shut down all certificate issuance. The production ACME endpoint returned HTTP 503 for roughly two and a half hours while the team investigated what turned out to be a flaw in the cross-signed certificates bridging its older Generation X root to the new Generation Y root. The incident formally closed on May 13 after the bad intermediates were revoked and reissued — but the ripple effects reached well beyond Let’s Encrypt’s own infrastructure.
What Happened
Let’s Encrypt has been transitioning from its established Generation X root certificates to a new Generation Y hierarchy. To maintain backward compatibility during the rollover, Let’s Encrypt issued cross-signed certificates that allowed the new Generation Y intermediates to chain back to the widely-trusted Generation X roots. This way, any browser or TLS client trusting either root could validate the chain.
On May 8, the cross-sign broke. Let’s Encrypt’s status page opened the incident with a single sentence confirming they were aware of a potential problem and were halting all issuance as a precaution. The ACME production directory at acme-v02.api.letsencrypt.org went down, and every ACME client attempting to issue or renew a certificate started getting errors.
About two and a half hours later, shortly after 21:00 UTC, issuance resumed. Let’s Encrypt rolled the tlsserver and shortlived ACME profiles back to issuing from the Generation X root — the same root the ecosystem has trusted for years. Browsers and TLS clients wouldn’t notice the difference. The Generation Y rollout, however, was paused.
The Root Cause: Missing EKU Fields
Five days later, on May 13, Let’s Encrypt published its postmortem and formally closed the incident. The root cause was specific and instructive: the cross-certified subordinate CAs bridging Generation X to Generation Y were missing Extended Key Usage (EKU) fields.
The CA/Browser Forum Baseline Requirements now mandate that a subordinate CA certificate used to issue TLS server certificates must explicitly carry the id-kp-serverAuth EKU. The original cross-signs had been issued without that field. Once the requirement took effect, the chain stopped validating — certificates issued through those intermediates could not be verified as legitimate for TLS server use.
The fix came in two phases. First, the operational rollback on May 8 that switched issuance back to Generation X. Second, on May 13, Let’s Encrypt revoked and reissued the affected cross-signs (X2/YR by X1, and YE by X2) with the correct EKU fields included. Importantly, end-entity certificates — the ones actually installed on websites — were not revoked, because they remained compliant on their own.
Who Was Affected
The blast radius extended beyond self-hosted ACME clients. DigitalOcean opened its own incident at 20:46 UTC on May 8, confirming that the Let’s Encrypt outage was breaking certificate issuance for Spaces, Spaces CDN, Load Balancers, and App Platform Custom Domains. Managed database operations (MongoDB, PostgreSQL, MySQL) were also stuck or delayed, since those services depend on Let’s Encrypt for TLS termination behind the scenes.
This is the part people forget: Let’s Encrypt is not just certbot on a VPS. Managed platforms depend on it too, often invisibly. When it goes down, the effects surface in services that most users would never associate with certificate issuance.
Existing certificates were not affected by the outage. TLS handshakes do not phone home to the issuing CA on every connection, and Let’s Encrypt retired its OCSP responders in August 2025. The only thing that broke was the ability to issue new certificates or renew expiring ones.
Why Short-Lived Certificates Raised the Stakes
The sites most exposed during the outage were those using Let’s Encrypt’s six-day shortlived certificate profile, which reached general availability in January 2026. Shortlived certs renew every two to three days, which means even a few hours of downtime eats a significant portion of the renewal window.
Standard 90-day certificates renewing at the 30-day mark had a comfortable buffer. A two-and-a-half-hour outage barely registers. But as the industry moves toward 45-day certificates — Let’s Encrypt switched its opt-in tlsserver profile to 45-day issuance just five days after this incident, on May 13 — and eventually to 47-day maximums by 2029, the margin for error during any CA disruption shrinks proportionally.
This was a relatively cheap lesson: fast diagnosis, clean rollback, no mass revocation. The next time a CA outage lasts a full working day instead of two hours, operators running shortlived certificates without fallback plans will feel it.
What to Do If You Were Affected
If you hold a certificate issued by the tlsserver or shortlived ACME profiles during the window when the flawed cross-signs were in use, Let’s Encrypt recommends renewing it so the chain picks up the corrected intermediate. The ACME Renewal Information (ARI) API is signaling affected certificates to renew immediately. Any ACME client that supports ARI — recent versions of certbot, acme.sh, and Caddy 2.7+ — will handle this automatically on the next scheduled run.
For anyone running an older client that does not support ARI, a manual certbot renew (or equivalent) followed by a chain check with openssl s_client -connect yourdomain.com:443 -showcerts will confirm the new intermediate is in place.
Lessons for Certificate Management
The pattern is the same one that shows up in most certificate outages:
- Automation is necessary but not sufficient. The renewal process itself needs monitoring. Silent failures — where a cron job logs an error that nobody reads — are how sites end up with expired certificates.
- CA concentration is a real risk. Let’s Encrypt serves roughly 63% of all TLS-enabled websites. When it halts issuance, the impact is not proportional to any single organization’s exposure — it cascades through managed platforms, CDNs, and services that depend on it invisibly.
- Shorter lifetimes demand better tooling. As maximum certificate validity drops from 200 days today to 47 days by 2029, the cost of any single renewal failure goes up. Organizations need visibility into when their certificates expire and whether their renewal processes are healthy.
SSLcalendar.com covers the renewal calendar. If you need chain validation, TLS health checks, and vulnerability detection across domains, SSLboard.com covers that broader view.
Sources: Let’s Encrypt Community Forum — Upcoming Profile Changes on May 13, mySites.guru — Let’s Encrypt Issuance Halted, May 2026, Cyber Security News — Let’s Encrypt Halts Certificate Issuance, DigitalOcean Status — Let’s Encrypt Outage Incident