Let's Encrypt: Failure to revoke key-compromised certificates within 24 hours
The case concerns Let's Encrypt’s revocation of certificates after receiving reports of key compromise. The reporter stated that between 2020-04-05 07:51:00 and 2020-04-05 07:51:21 UTC, 12 revocation requests were sent to c**********s@letsencrypt.org for 42 certificates and precertificates, and that the OCSP revocationTime values observed were 2020-04-06 08:19:09 or 2020-04-06 08:19:10—more than 24 hours after the reports were submitted. The reporter argued this violated the requirement to revoke within 24 hours when key compromise evidence is obtained. In response, a Let's Encrypt employee summarized that 12 subsequent key-compromise reports were received, and that investigation, revocation, and key blocking were performed 28 minutes after the 24-hour revocation deadline. They provided a timeline indicating that 24 serials associated with the reported compromised keys were found and revoked at 2020-04-06 08:19:00, and stated that the compromised keys were added to a blocklist to prevent future issuance using those keys. They also explained that an email went unanswered for 11 hours, triggering a secondary notification, and that the initial reports were discovered only after that secondary notification; they said they missed the deadline by 28 minutes and planned to add additional monitoring and alerting. The bug is marked RESOLVED with resolution FIXED.
- Let's Encrypt received 12 emails reporting key compromise via c**********s@letsencrypt.org.
- Let's Encrypt found and revoked 24 serials associated with the reported compromised keys and added the compromised keys to a blocklist.
- Mozilla CA Program bug was created to report delayed revocation after key-compromise reports.
- Hezmatt representative — Reported that OCSP revocationTime values for the affected certificates were observed more than 24 hours after the key-compromise reports were submitted.
- Community commenter — Asked whether the revocation time shown in the CRL or OCSP response alone was sufficient and noted the report did not indicate whether evidence of a failure to revoke was recorded.
- Hezmatt representative — Provided a table showing revocationTime and OCSP status transitions for the certificates around the revocation period.
- Internet Security Research Group — Submitted a summary and timeline stating that revocation and key blocking occurred 28 minutes after the 24-hour deadline, explained why the deadline was missed, and listed steps and tooling for handling key-compromise reports.
- Community commenter — Commented that Comment #3’s response appeared to indicate the timeline of changes was already implemented based on past-tense wording.