1635840 - Sectigo: Failure to properly respond to a report of subscriber key compromise

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Robin Alden]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36

Steps to reproduce:

A report was posted to m.d.s.p at 16:46BST on Monday 4th May 2020 that states that evidence of a compromised subscriber key was provided to Sectigo on 1st May but the report was not acknowledged as being valid and the certificate using the compromised key, was not revoked.

I acknowledge that this is a valid incident report and I will follow up in this ticket with an incident report in the expected format.

Comment 1

[Robin Alden]

1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

Posts to m.d.s.p.
16:46 BST on Monday 4th May 2020
https://groups.google.com/d/msg/mozilla.dev.security.policy/dIvMXpL2Ysc/Seu9RKRRAgAJ

2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

2019 Aug 18 We released our self-service revocation portal as first mentioned in Bug #1492006.

following dates are all in 2020
May 01 15:03 BST
Sectigo received an email to our problem reporting mailbox claiming to attach a CSR proving compromise of the key for https://crt.sh/?id=2081585376

May 01 17:68 BST
Sectigo responded by email "Thank you for bringing this to our attention. We will begin an investigation immediately and inform you of any relevant updates."

May 01 19:24 BST
Sectigo responded by email "It appears that the CSR you sent us is not the correct CSR. When we decode the CSR you sent it decodes to "CN=The key that signed this CSR has been publicly disclosed. With this information we cannot use this CSR to revoke the current cert to prove that it has been compromised. Also PwnedKeys says it’s not compromised with the CSR the cert is issued from. Please let us know if you need any additional details."

May 02 16:33 BST
Sectigo received an email "I would like to challenge your assessment of this revocation request. Requesting you provide a technical write-up as to why you think this is not a compromise. Your only explanation for why this is not compromised is 1) The CN value? Not sure what you were expecting in the CN field?? 2) something about pwnedkeys says it's not compromised?? what's pwnedkeys have to do with my report? Also, why are you holding them as some sort of authority and what is it exactly that "says it's not compromised" ?
Note, you have failed to adhere to the 24-hour revocation of this certificate under an incomplete and incorrect review.
thanks,"

May 05 17:50 BST
Sectigo responded by email "https://crt.sh/?id=2081585376. Please provide more details or proof that the private key is actually compromised. The CSR provided looks dummy and it is not used in the above issued certificate."

May 06 20:30 BST
Sectigo responded by email "Our checks based on your information did not show the private key for the domain faithful-to-nature.co.za is compromised. Please provide additional information so the we can confirm your report.
1 - How did you obtained a private key for the domain faithful-to-nature.co.za
2 - Do you have the private key in your possession and if so, please give us the private key
3 - Is the private key published on a public facing website and if so, where?
4 - Were you given the private key exported from the organization's web server?
Regards,"

May 06 23:20 BST
Sectigo revoked the certificate https://crt.sh/?id=2081585376.

May 07 18:35 BST
Sectigo responded by email "The certificate was revoked May 5, 2020 6:20 PM ET. ()
Thank-you for the report.
Regards,"

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

This is not an issuance problem, but a concern over the speed of response over a revocation request.

4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

https://crt.sh/?id=2081585376 issued Nov 07 2019, revoked May 06 2020

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

The Sectigo customer service staff that received the problem were not sufficiently familiar with the form of proof of revocation provided by the reporter.
We appreciate that the proof was genuine, but it was not one we were fully prepared to receive and process and that is why there was a delay in processing the report.

We apologize that the revocation of this certificate was delayed.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

We have added a further automated revocation mechanism for compromised keys and we have documented in our CPS the mechanisms we provide that enable a speedy response to key compromise reports. Our recently updated CPS, available under https://sectigo.com/legal, includes the details of these, but for convenience I include a snippet from that document here.

• Sectigo also operates an automated revocation portal at https://secure.sectigo.com/products/RevocationPortal where Subscribers/Domain owners may revoke their certificates, or the public may report and revoke certificates for which the private key has been compromised.
• The public may also report and revoke certificates for which the private key has been compromised by using the ACME revokeCert method at this endpoint:
ACME Directory: https://acme.sectigo.com/v2/keyCompromise
revokeCert API: https://acme.sectigo.com/v2/keyCompromise/revokeCert

Comment 2

[Ben Wilson]

This incident appears to be appropriately explained, documented and remediated, therefore I am going to close it.

Comment 3

[mpalmer]

I don't see any indication of what remediation was performed to prevent this exact same incident from happening again in the future.