Closed Bug 1639802 Opened 2 years ago Closed 1 year ago

Digicert: Failure to revoke key-compromised certificate


(NSS :: CA Certificate Compliance, task)


(Not tracked)



(Reporter: mpalmer, Assigned: brenda.bernal)


(Whiteboard: [ca-compliance])

Steps to reproduce:

At 2020-05-08 13:57:08 UTC, a certificate problem report was sent to ( on behalf of, stating that a private key with SPKI 6da7c7d14adafc75d98d61021f0a606fd367050243e8fe2bf52b753362f86413 had been compromised, and requesting revocation of all certificates issued by Digicert using the specified SPKI. The URL of a CSR attesting to the compromise of the private key, signed by the compromised private key, was provided.

Actual results:

Certificates and were revoked within 24 hours of receiving the certificate problem report, based on validly signed OCSP responses. However, as of the time of submission of this bug, validly signed OCSP responses for certificate are showing the certificate as being valid.

Expected results:

All certificates to have been revoked within 24 hours of the problem report being received.

Assignee: bwilson → brenda.bernal
Ever confirmed: true
Whiteboard: [ca-compliance]

This is the same issue as this:

Just with a different key. Again, we searched, found the keys, sent out the revocation notice and before revocation but after searching, a new cert was issued. Our expected timeframe for remediation and having something that blocks key reuse between when the search ends and when we revoke is still June.

Could we combine this one with the other bug? I can update the incident report to include this one as well.

I'm ambivalent about whether or not to combine the two incidents. However, I'd like to highlight this from the previous incident report:

the short term solution is to scan the database both before and after we revoke the reported cert.

That was written more than a month before this incident occurred. I would have expected that it would take less than a month for a "short term solution" such as this to be deployed.

Hey Ben - Can we close this as duplicate of

Flags: needinfo?(bwilson)

I'm not Ben, but I don't think this should be combined, for the reason Matt highlights in Comment #3. There's a distinct failure mode here that short term mitigations were supposed to catch, but didn't.

Flags: needinfo?(jeremy.rowley)

The short term fix is/was super manual, and relies on people running a scan every time. There isn't a good reason for the miss other than people forgot to include some certs in the rescan. There's a couple dozen every other day and the rescan isn't part of any automation. It relies solely on the support staff remembering to do this for every cert after revocation occurs.

Flags: needinfo?(jeremy.rowley)

I am going to hold off on combining these for now.

Flags: needinfo?(bwilson)

It relies solely on the support staff remembering to do this for every cert after revocation occurs.

That... doesn't seem like a good procedure. Humans are generally not great at doing boring, repetitive work, which is why we have computers.

Yeah - hence the emphasis on a short term/stop gap solution. It's only there until we get the key blacklister in place.

It wasn't felt that it was necessary to have any sort of management oversight or control, QA, or anything like that on the process, to ensure it was actually being carried out?

Tracking June 30 for the blacklist key checker being roled out for DigiCert. Quovadis and non-TLS coming after.

See the other bug. I think this one can be closed.

Ben: While Bug 1624527 tracks the automated responder, I think we can mark this as Resolved/Fixed (not Resolved/Duplicate). DigiCert implemented short-term mitigations that failed/were inadequate, but followed up with longer-term mitigations. I think of this as distinct, and something more to keep in mind in future short-term mitigations, but otherwise seems resolved.

Flags: needinfo?(bwilson)
Closed: 1 year ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.