Let's Encrypt self-reported CRL early-removal incident with follow-up replication-lag audit

Let’s Encrypt self-reported an incident in which monitoring detected that some published CRLs temporarily omitted recently added revocation entries before the affected certificates expired. The thread says the cause was a database replication issue triggered during network instability, and that subsequent CRL updates correctly contained the affected entries. Let’s Encrypt stated that no invalid certificates were produced, issuance was not stopped, and all previously revoked certificates remained revoked. Later comments added that Let’s Encrypt completed an audit of Boulder database interactions and identified several read operations where high replication lag could create compliance concerns. The follow-up discussion also clarified that the bad-key-revoker reads blocked keys and issued certificates from the primary database only, and that Let’s Encrypt does not serve any other forms of revocation information. The bug remains ASSIGNED, with Let’s Encrypt asking for the CRL Next-Update field to be extended while remediation work continues.

1. 2026-06-03 Let’s Encrypt reports that a database replication issue caused recently added revocation entries to be temporarily omitted from some CRLs.
2. 2026-06-17 Let’s Encrypt posts a full incident report with impact counts, timeline, and confirmation that no invalid certificates were produced.
3. 2026-07-17 Let’s Encrypt reports completion of an audit of Boulder database interactions and requests a later Next-Update date.
4. 2026-07-24 Let’s Encrypt answers follow-up questions about replication lag, mitigation timing, and which Boulder operations read from replicas.

1. 2026-06-03 Internet Security Research Group — Posted a preliminary incident report saying crl-monitor detected CRLs temporarily missing recently added revoked serial entries due to a database replication issue.
2. 2026-06-17 Internet Security Research Group — Posted the full incident report with the timeline, impact counts, and statement that revocations were not delayed and no invalid certificates were produced.
3. 2026-06-23 Internet Security Research Group — Requested that the Next Update field be set to 2026-07-17 because remediation items were still ongoing.
4. 2026-07-17 Internet Security Research Group — Reported completion of an audit of database interactions in Boulder release tag v0.20260713.0 and requested setting Next-Update to 2026-09-30.
5. 2026-07-19 Community commenter — Asked questions about replication-lag detection, mitigation timing, deferred safeguards, the follow-up audit, and whether fixes would be shared upstream.
6. 2026-07-24 Internet Security Research Group — Answered that stalled replication is already detected, explained the mitigation delay, described the audit findings, and said the bad-key-revoker reads only from the primary database.