Let’s Encrypt and the CAA Mis-Issuance Freeze That Disrupted the Web’s Trust Model

In late February 2020, the internet’s certificate infrastructure experienced an unexpected jolt when Let’s Encrypt, the world’s largest provider of free SSL/TLS certificates, announced a mass revocation affecting millions of active certificates. At the heart of the issue was a mis-implementation related to the Certificate Authority Authorization (CAA) standard—a subtle but critical policy designed to help domain owners control which certificate authorities (CAs) can issue certificates for their domains. The flaw forced Let’s Encrypt to declare a sudden freeze on new certificate issuance and initiate a mass recall affecting over three million certificates in circulation. The event exposed the fragility of web trust, the complexity of compliance in cryptographic ecosystems, and the cascading impact a single logic error can have on internet infrastructure.

The CAA standard, formalized in RFC 6844 and later refined by RFC 8659, is a DNS-based mechanism that allows domain owners to explicitly authorize which CAs may issue certificates for their domains. Before a CA issues a certificate, it is required to perform a CAA check by querying the domain’s DNS records to confirm that issuance is allowed. This check helps prevent unauthorized or mistaken issuance, particularly useful in the event of CA compromise or human error. The CAA check must be performed and respected within a narrow time window—typically no more than eight hours prior to issuance.

Let’s Encrypt, operated by the nonprofit Internet Security Research Group (ISRG), relies on automation and scale to deliver certificates efficiently. Its ACME (Automatic Certificate Management Environment) protocol allows users to request and renew certificates with minimal manual intervention. It was within this automation framework that the CAA mis-issuance bug occurred. On February 29, 2020, a researcher disclosed that Let’s Encrypt’s validation logic contained a subtle flaw: under certain conditions, it failed to recheck the CAA record for each domain name (or subdomain) within a certificate request. If a domain owner had recently changed their CAA policy to disallow issuance by Let’s Encrypt, the authority might still issue the certificate if it had cached a previous, now-outdated validation result—thus violating the CAA compliance window.

The bug affected the issuance pipeline in a narrow but dangerous way. In multi-domain certificates (those with Subject Alternative Names or SANs), Let’s Encrypt’s validation code occasionally skipped the CAA re-check if it had already validated a different domain on the same account or certificate request. While this behavior wasn’t malicious, it meant the CA could unintentionally issue a certificate without honoring the current CAA policy for every domain listed. In the complex dance of trust that underpins HTTPS, such an error is significant.

Upon verifying the issue, Let’s Encrypt acted quickly. The organization identified over three million certificates that had been issued under potentially non-compliant conditions due to the CAA logic flaw. Under the rules set by the CA/Browser Forum—the industry consortium governing CAs—Let’s Encrypt was obligated to revoke any certificate that had not been issued according to proper validation. Let’s Encrypt gave affected domain owners a window of 5 days to renew their certificates or face revocation.

This triggered an urgent scramble. Hosting providers, sysadmins, and website operators who relied on Let’s Encrypt were suddenly put on high alert. For many, certificates are auto-renewed and largely invisible in daily operations. The prospect of a forced revocation, which would break HTTPS connections and trigger browser security warnings, posed a significant operational risk. To assist users, Let’s Encrypt provided a tool for checking affected certificates by domain name and updated its public logs through the Certificate Transparency ecosystem. Still, the scale of the revocation effort was unprecedented.

Due to the immense impact, Let’s Encrypt ultimately revoked around 1.7 million of the affected certificates—just over half of the total initially identified. The others were left untouched because affected domains had successfully renewed with properly validated certificates before the revocation deadline. The episode nevertheless represented one of the largest coordinated certificate recall efforts in history.

From a technical perspective, the bug was neither complex nor obscure. It was, fundamentally, a logic error—an oversight in the automated handling of domain validation states. But in the high-stakes world of public key infrastructure (PKI), where trust is binary and enforcement is distributed, even small errors have magnified consequences. The incident laid bare the critical nature of compliance automation in certificate issuance, especially for services like Let’s Encrypt that operate at web-wide scale. At the time, Let’s Encrypt was issuing over a million certificates per day, and a flaw in its logic had the potential to erode confidence in the web’s encryption backbone.

It also served as a reminder of how newer security features, like CAA, while powerful, introduce additional complexity. The CAA standard was meant to improve resilience against mis-issuance, but it required correct implementation and strict adherence to time windows. Let’s Encrypt’s failure to recheck certain CAA records at issuance time—even if due to caching or optimization—demonstrated how even good-faith engineering can fall short of protocol intent.

Browser vendors, security researchers, and competing CAs responded with measured concern. While Let’s Encrypt’s rapid disclosure and remediation efforts were praised, the event reignited discussions about the role of auditability, transparency, and real-time monitoring in certificate infrastructure. Certificate Transparency logs provided a crucial tool for verification, but they could not prevent errors in issuance—they only made them visible after the fact. More proactive defenses would require deeper integration between DNS operators, domain owners, and certificate request flows.

For its part, Let’s Encrypt took the incident seriously, re-auditing its issuance pipeline and reworking its validation logic to ensure CAA checks were fully compliant on every issuance, regardless of domain overlap or validation caching. The organization also reiterated its commitment to open communication and security best practices, even when the outcomes were operationally painful.

The CAA mis-issuance freeze of 2020 was not a security breach in the traditional sense—no attackers exploited the flaw, and no data was stolen. But it was a breach of protocol, a crack in the foundational processes that uphold the integrity of the HTTPS ecosystem. In an era where most of the web is encrypted by default, and where trust in digital certificates underpins everything from banking to email to government communication, such errors are not merely technical—they are structural weaknesses in the architecture of online trust.

Let’s Encrypt survived the incident with its reputation largely intact, a testament to the transparency and speed with which it handled the situation. But the episode stands as a clear warning that in a system as distributed and fragile as the modern web, even the most well-intentioned optimizations can lead to systemic failure if compliance takes a back seat to convenience. It was a moment that reminded everyone—users, developers, and CAs alike—that trust on the internet is hard-won, easily lost, and dependent on precision at every layer.

In late February 2020, the internet’s certificate infrastructure experienced an unexpected jolt when Let’s Encrypt, the world’s largest provider of free SSL/TLS certificates, announced a mass revocation affecting millions of active certificates. At the heart of the issue was a mis-implementation related to the Certificate Authority Authorization (CAA) standard—a subtle but critical policy designed to…