Sectigo: Failure to revoke certificate with previously-compromised key within 24 hours
This case concerns Sectigo’s revocation timing for certificates whose subscriber private keys were previously reported as compromised. An external reporter (via mozilla.dev.security.policy) notified Sectigo on 2020-03-20 that a specific certificate was using a publicly disclosed compromised private key, and Sectigo revoked that certificate with a revocation timestamp of 2020-03-20 19:37:48 UTC. The reporter then observed that a subsequent certificate was issued by Sectigo using the same SPKI as the previously reported compromised key, and that the new certificate did not appear as revoked in crt.sh via CRL or OCSP as of 2020-03-27. The reporter argued this indicated a failure to revoke within 24 hours of issuance, which they believed violated Mozilla policy. Sectigo provided an incident report describing how it received the compromise report, acknowledged it, and revoked a set of certificates, and it stated it had put interim measures in place so that new certificates with compromised keys would be revoked within 24 hours. Sectigo also explained that its systems did not automatically check for compromised key reuse at certificate issuance or acceptance, and that searching for other certificates using compromised keys was not consistently performed as an integral part of revocation report processing. Sectigo stated it revised the revocation script and runs it twice a day, and that the procedural measure requires notifying subscribers to revoke and replace certificates within 24 hours. The bug was resolved as FIXED, and the reporter confirmed their questions were answered.
- Sectigo revoked a certificate after receiving notice that its subscriber private key had been compromised.
- Sectigo issued a new certificate using the same SPKI as the previously reported compromised key.
- The reporter observed the new certificate did not appear revoked via CRL or OCSP on crt.sh.
- Sectigo provided details on its incident response and remediation steps for revocation timing and key-compromise checking.
- Fastly representative — Reported that a certificate using a publicly disclosed compromised key was revoked, but a subsequent certificate using the same SPKI was not shown as revoked on crt.sh within the expected 24-hour window.
- Sectigo — Requested that Sectigo provide an incident report.
- Sectigo — Submitted an incident report with a timeline of actions, described interim measures to revoke new compromised-key certificates within 24 hours, and explained issues in how compromised keys were handled.
- Hezmatt representative — Asked whether the revocation-identification script covered all previously reported compromised keys and requested details on the interim measures and why key-compromise searching was not consistently done.
- Sectigo — Explained that the script was revised to use a driving list of public keys for TLS certificate revocations with key-compromise reason, stated it is run twice a day, and described procedural subscriber notification since the script does not prevent new issuance.
- Hezmatt representative — Confirmed all questions were answered.