Summary

  • Let's Encrypt disclosed on 29 February 2020 that its CA software, Boulder, had a bug in the way it rechecked DNS Certification Authority Authorization records for certificate requests containing multiple names. The organization said issuance was halted minutes after confirmation and resumed after a fix was deployed [1].
  • CAA is a DNS resource record that lets a domain name holder state which certificate authorities are authorized to issue certificates for that domain. RFC 8659 frames it as an additional control against unintended certificate mis-issuance, not as an optional brand label [2].
  • The accountability issue was not whether Let's Encrypt supported CAA in general. It was whether every covered name in a reused validation set received the required fresh authorization check close enough to issuance, and whether affected subscribers could replace certificates before revocation [1].
  • A separate production precedent in the BTW directory links Let's Encrypt certificate-trust coverage to entity:internet-society; the direct public subject in this article remains Let's Encrypt and the Internet Security Research Group service described by the official Let's Encrypt about page [3].
  • The practical control lesson is that DNS policy, CA software, subscriber automation and public revocation communication must be auditable as one chain. A relying party cannot inspect private CA logs, so public postmortem evidence and deterministic recurrence controls become part of the trust boundary.

What happened

Let's Encrypt's incident notice described a defect discovered on 29 February 2020 in Boulder, the CA software it uses for issuance. Boulder normally checks CAA records when it validates a subscriber's control of a domain name. Because some validations remain usable for a period after the initial check, a certificate authority may need to check CAA again just before issuing a certificate. Let's Encrypt said the applicable rule required a CAA check within eight hours before issuance when the validation was older than that [1].

The failure mode was specific. When a request contained multiple domain names that needed CAA rechecking, Boulder selected one domain name and checked it repeatedly instead of checking each relevant name. That meant a certificate request could pass through issuance even though one or more names in the request had not received the intended fresh DNS authorization check. Let's Encrypt said it confirmed the bug at 03:08 UTC, halted issuance at 03:10 UTC, deployed a fix at 05:22 UTC and then re-enabled issuance [1].

That timeline matters because certificate authority accountability is not proved only by saying that the code was corrected. The system also had to identify certificates that might have been issued without the required recheck, notify subscribers, enable replacement and carry out revocation. The incident thread later directed subscribers to renew and replace affected certificates before revocations began. The public record therefore included three operational stages: defect identification, issuance fix and certificate lifecycle cleanup [1].

Why CAA is a DNS control, not a paperwork field

RFC 8659 defines the DNS CAA resource record as a way for a domain name holder to specify which certificate authorities may issue certificates for that domain. The same standard says CAA gives public CAs an additional control to reduce unintended certificate mis-issuance [2]. In practice, that makes CAA a boundary between the domain operator's DNS state and the CA's issuance decision.

For Daniel Kade's risk-and-accountability scope, the important point is not the certificate brand. It is the operational authority chain. A domain owner publishes CAA in DNS. Recursive and authoritative DNS infrastructure returns the record state seen by the CA. The CA software interprets that state according to issuance rules. Subscriber automation expects renewal to work at scale. Relying parties trust that a public certificate was issued under the required controls. If one link in that chain is compressed into a vague "validation passed" label, the evidence boundary becomes too soft.

The 2020 bug exposed exactly that softness. Domain control validation and CAA authorization are related, but they are not the same test. A subscriber can still control a domain while the domain's CAA policy has changed, while DNS responses differ across time, or while one name in a multi-name certificate request requires a separate check. Accountability requires logs and tests that preserve the distinction.

The directory and subject boundary

The current production directory has a published internet-society entity and no separate current published entity for Internet Security Research Group or Let's Encrypt. That is not a reason to invent an entity or to relabel the incident. The article's source subject is Let's Encrypt and the ISRG service described by the official Let's Encrypt about page [3]. The directory binding uses the existing Internet Society precedent already present in production for a previous Daniel Kade Let's Encrypt certificate-trust article, while the body keeps the direct subject clear and does not claim that the Internet Society made the 2020 Boulder engineering decision.

That distinction is necessary for source fidelity. A directory row is a production linkage surface. The incident facts must still be attributed to the organization that disclosed them and to the standards documents that define the control. If the importer or owner gate requires a direct ISRG entity before publication, this candidate should fail closed rather than be forced through the wrong organization.

What accountability evidence should show

A defensible closeout after this class of issue should answer at least six questions.

First, what names in a request required fresh CAA rechecking, and why? The answer should be derivable from validation age, issuance time, and the certificate's subject alternative names, not from a manual spreadsheet after the fact.

Second, what DNS answers did the CA rely on? CAA is a DNS record, so the evidence boundary should include query timing, resolver behavior, authoritative answers where retained, and error handling for timeout or SERVFAIL cases.

Third, which software path made the decision? A postmortem should show whether the code iterated over every relevant name, whether tests covered multi-name requests, and whether the recurrence control would fail if the same class of bug returned.

Fourth, what certificates were potentially affected? The impact set should be a reproducible query over issuance data, not an estimate that cannot be independently bounded.

Fifth, how were subscribers notified and how was replacement tracked? Revocation is only the visible endpoint. The operational risk is the gap between a subscriber receiving notice, renewing successfully and old certificates becoming invalid.

Sixth, what changed in monitoring? A one-time fix is weaker than a permanent check that alerts when issuance logic, CAA lookup count and certificate name count diverge.

Why this matters beyond Let's Encrypt

Large certificate authorities operate at a scale where small validation assumptions can affect many subscribers quickly. Automation is part of the security model: it reduces manual errors and makes HTTPS easier to deploy. But automation also means that an incorrect control can repeat at machine speed until halted. That is why the accountability layer cannot depend on trust in intent. It has to depend on evidence that shows what code ran, what DNS state was consulted and what lifecycle action followed.

The same lesson applies to registrars, DNS operators, hosting providers and managed certificate platforms. If an organization lets customers request certificates, rotate DNS records, delegate zones or automate TLS renewal, it needs a record of the authority it used at the moment of action. A control that is correct at validation time but stale at issuance time is not current authorization.

What to watch now

The long-term signal is whether certificate authorities and hosting platforms keep CAA behavior testable as issuance products become more automated. Operators should watch for incidents that mention validation reuse, multi-name certificate requests, resolver failures, emergency revocation, account-level authorization, ACME client behavior and subscriber notification windows. Each of those terms can mark a boundary where a control is silently being treated as already satisfied.

The lower-risk scenario is clear: every name is rechecked under current policy, issuance is blocked when CAA does not authorize it, affected certificates are identifiable, subscribers can renew without outage, and revocation is completed with public evidence. The higher-risk scenario is also clear: validation, authorization, issuance and revocation are merged into one opaque status, leaving users to trust that a private control worked.

Sources

  1. https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591
  2. https://www.rfc-editor.org/rfc/rfc8659
  3. https://letsencrypt.org/about/