Let’s Encrypt Pauses Certificate Issuance After Internal Error

On May 8, 2026, Let’s Encrypt temporarily stopped issuing certificates after detecting an internal error in its certificate system. Existing certificates remained valid, but new requests and automated renewals were affected during the interruption. Service was later restored after Let’s Encrypt changed the affected issuance path.

What Happened Inside Let’s Encrypt?

The interruption traced back to Let’s Encrypt’s newer Generation Y certificate hierarchy. A cross-signed path between the older Generation X root and the newer Generation Y root was missing the expected Server Authentication marker required for TLS certificates.

On the surface, that sounds minor. Inside public trust infrastructure, it’s not. Certificate ecosystems rely on tightly controlled chains where even a small mismatch can disrupt automated renewals and new certificate requests at scale.

Let’s Encrypt responded by temporarily stopping certificate issuance, rerouting affected issuance paths back through its older Generation X root, and restoring service later the same day. Existing certificates continued working during the interruption.

This is not the first time Let’s Encrypt has had to move quickly after a certificate-system mistake. In 2020, the CA prepared to revoke more than 3 million certificates after discovering a flaw in how CAA records were rechecked during issuance. 

That incident was unrelated to the current disruption, but it exposed the same operational reality: large-scale certificate automation still depends on extremely precise controls.

The Growing Pressure Behind Certificate Issuance 

This disruption hits just as the certificate industry moves toward shorter lifespans and faster renewal cycles. While Let’s Encrypt already uses 90-day certificates, commercial CAs are gearing up for even shorter windows in the near future.

That shift is driving a sharp increase in renewals, validations, and chain updates flowing through hosting platforms, CDNs, enterprise networks, and automated deployment systems every day.

To make matters worse, the incident comes only days before Let’s Encrypt rolls out 45-day certificate profiles for early adopters, a move that will further ramp up renewal frequency across automated systems.

The Automation Stakes for Enterprise IT

For large-scale networks, the interruption acted as a stress test for automated certificate management. Many modern environments rely on the “set it and forget it” promise of ACME clients, but when certificate issuance stops upstream, automation can quickly become part of the problem instead of the solution.

If renewal systems keep retrying against a broken issuance path, they can trigger rate limits, queue backlogs, or timeout issues that persist even after the CA restores service. The incident may push more infrastructure teams to look more closely at multi-CA redundancy, where backup providers such as Google Trust Services help reduce dependence on a single issuance source.

SSL Dragon’s Take

The missing “Server Authentication” marker may sound like a small technical detail, but the incident highlights how sensitive modern certificate infrastructure has become as lifetimes continue shrinking.

In the era of two-year certificates, a short issuance delay was usually little more than an operational annoyance. In a world moving toward 45-day and eventually much shorter certificate lifespans, even brief disruptions can affect a far larger volume of renewals across automated environments.

Shorter lifetimes improve security by reducing exposure to stolen keys and outdated cryptography. But they also raise the reliability standard for certificate infrastructure operating behind the scenes.

As the industry moves toward shorter certificate lifetimes, your organization needs automation it can monitor and trust. SSL Dragon provides ACME-ready SSL solutions, certificate monitoring tools, and flexible CA options for modern infrastructure environments.