Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours

This case reports that Let's Encrypt issued certificates more than 24 hours before they were revoked, and that certain key-compromised certificates remained unrevoked despite revocation of other certificates using the same private key. The report was raised on Mozilla’s security policy forum and referenced two specific certificates that were issued more than 24 hours earlier and were still unrevoked. Let's Encrypt explained that its procedure for blocking compromised keys was triggered by key-compromise reports received via the contact methods listed in its CPS, and that certificates revoked via the ACME API were not previously used to block keys for future issuance or revoke other certificates with the same key. In response, Let's Encrypt blocked the compromised keys and revoked certificates issued with those keys, and it described interim and longer-term remediation steps, including automation to check for keyCompromise revocations and add keys to a blocklist, plus scanning and revoking affected certificates. Later updates stated that the ACME API now automatically adds the SPKI hash to a blocked keys table and triggers automatic revocation of matching valid certificates, and that the CPS was updated to reflect the ACME API procedure. The bug was marked RESOLVED with resolution FIXED, and a participant stated that remediation was complete.

1. 2020-03-19 Let's Encrypt issued multiple certificates and later revoked some of them via the ACME API for keyCompromise.
2. 2020-03-20 A third party posted a report on the Let's Encrypt community support forums about previously revoked private keys.
3. 2020-03-26 A Mozilla Bugzilla report was opened about unrevoked key-compromised certificates.
4. 2020-03-31 Let's Encrypt blocked issuance for the two compromised keys and revoked additional certificates issued with those keys.
5. 2020-05-19 Let's Encrypt reported that ACME API keyCompromise revocations now automatically add SPKI hashes to a blocked keys table and trigger automatic revocation and notifications.
6. 2020-05-29 Let's Encrypt updated its CPS to state that keys will be blocked and affected certificates revoked when the ACME API is used with reason keyCompromise.

1. 2020-03-26 Community commenter — Reported that two certificates issued more than 24 hours earlier remained unrevoked despite revocation of other certificates using the same private key, and asked for an incident report.
2. 2020-03-26 Community commenter — Asked Josh Aas to provide an incident report for Let's Encrypt and referenced a related discussion.
3. 2020-03-31 Internet Security Research Group — Explained that key blocking was triggered by CPS contact methods and not by ACME API revocations, and stated plans to implement automated key blocking by May 14, 2020.
4. 2020-04-04 Hezmatt representative — Questioned whether Let's Encrypt’s approach complied with the BRs and asked what steps were taken in the interim.
5. 2020-04-05 Internet Security Research Group — Provided rationale for the prior anti-abuse approach and described interim remediation, including generating lists of subscriber-revoked keyCompromise certificates and manually revoking affected certificates.
6. 2020-04-13 Internet Security Research Group — Said additional remediation included automation to check logs every 15 minutes, block compromised keys, scan for affected certificates, and revoke as necessary.
7. 2020-05-19 Internet Security Research Group — Updated that a bug delayed the May 14 change, but that ACME API keyCompromise revocations now automatically add SPKI hashes to a blocked keys table, revoke matching certificates, and notify subscribers.
8. 2020-05-29 Internet Security Research Group — Reported that the CPS was updated to clearly state that keys will be blocked and affected certificates revoked when the ACME API is used with reason keyCompromise.
9. 2020-05-29 Fastly representative — Stated it appeared all questions were answered and remediation was complete.