Sectigo: Failure to revoke certificate with compromised key

[sandy...@gmail.com]

I submitted a compromised key report to Sectigo [ssl_...@sectigo.com] on 1 May 2020 at 2:03pm UTC but Sectigo failed to revoke the certificate per cab-forum guidelines [4.9.1.1. Reasons for Revoking a Subscriber Certificate].

Upon submitting my report [case ref: _00D1N2Ljih._5003l11VztU], I received an automated response at 1 May 2020 at 2:03pm UTC and the first human response came 4 hours later on 1 May 2020 at 6:24pm UTC with what I believe was an incorrect assessment and failure to carefully review the evidence provided. The impacted certificate as of writing this post is still not revoked.

The certificate in question: https://crt.sh/?id=2081585376

A CSR signed by the original private key was provided with the following subject details as evidence of possession:
CN = The key that signed this CSR has been publicly disclosed.
O = Compromised Key

The response I received from Sectigo failed to demonstrate competency to deal with report and instead made references to the commonName attribute as being a problem, however without providing any form of explanation as to what is wrong with it? Additionally, Sectigo referred to pwnedkeys as some sort of authority that they say it’s not compromised. However, I suspect what Sectigo staff really meant is they were unable to find the spki sha256 fingerprint against pwnedkeys database but I don’t see how that means anything or why they are checking pwnedkeys when the evidence was attached along with the report. The necessary evidence was provided to Sectigo and they have thus far failed to deal with the evidence or clearly articulate reasons for concluding this case to not be a compromise.

I have sent further emails to Sectigo over 24 hours ago requesting their decision to be carefully reviewed and have still not received a reply. I suspect my case was closed and response went into a blackhole.

I would like to request Sectigo to again review this matter, revoke the certificate and provide an incident report.

[Ryan Sleevi]

Thanks for sharing this. Could I ask you to post the CSR and/or
evidence you shared somewhere?

Mostly to help confirm that indeed, Sectigo did make the wrong call,
and that this is an incident :) I was in the process of writing up the
Bugzilla bug and realized it probably makes sense to do a little due
diligence myself. Sectigo is expected to be watching this mailing list
and can also respond (and open the Bugzilla incident). I just didn't
recognize your e-mail / past posts, and so wanted to at least confirm
before making noise :)

[Matt Palmer]

On Mon, May 04, 2020 at 08:45:34AM -0700, sandybar497--- via dev-security-policy wrote:
> Additionally, Sectigo referred to pwnedkeys as
> some sort of authority that they say it’s not compromised.

Bless their little cotton socks, pwnedkeys is now such an authority that
Sectigo thinks I've got every compromised key in existence. I feel so
validated.

> The necessary evidence was provided to Sectigo and they have thus far
> failed to deal with the evidence or clearly articulate reasons for
> concluding this case to not be a compromise.

What I've found works best when reporting these cases to m.d.s.p is to
provide all the (substantive) correspondence, exactly as it was
sent/received, along with UTC timestamps. That allows for independent
assessment that Sectigo has, in fact, fallen down on the job, rather than it
being possible that there's just a big ol' misunderstanding going on.
Here's an example of the sort of thing I mean:

https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/wtM7uX1stIA

- Matt

[Robin Alden]

> > The necessary evidence was provided to Sectigo and they have thus far
> > failed to deal with the evidence or clearly articulate reasons for
> > concluding this case to not be a compromise.
>
> What I've found works best when reporting these cases to m.d.s.p is to
> provide all the (substantive) correspondence, exactly as it was
> sent/received, along with UTC timestamps. That allows for independent
> assessment that Sectigo has, in fact, fallen down on the job, rather than it
> being possible that there's just a big ol' misunderstanding going on.
> Here's an example of the sort of thing I mean:
>
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/wtM7
> uX1stIA
>
> - Matt

I can see the report in to our problem reporting mailbox (ssla...@sectigo.com) and the ticket on our side.
I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1635840 and I will follow up with an incident report in that bug.

Regards
Robin Alden
Sectigo

[sandy...@gmail.com]

In the latest reply from Sectigo I am advised "The CSR provided looks dummy and it is not used in the above issued certificate.". Although Sectigo continues to disagree with the evidence provided they did not provide me with specific directions as to what proof they would consider but according to their reply it would seem a copy of the original CSR would suffice. This is a deeply concerning response from Sectigo.

Here is a copy of the CSR as provided to Sectigo

-----BEGIN CERTIFICATE REQUEST-----
MIICozCCAYsCAQAwXjEYMBYGA1UECgwPQ29tcHJvbWlzZWQgS2V5MUIwQAYDVQQD
DDlUaGUga2V5IHRoYXQgc2lnbmVkIHRoaXMgQ1NSIGhhcyBiZWVuIHB1YmxpY2x5
IGRpc2Nsb3NlZC4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDL7fFo
EIq/60Ai9XO9pYiUQc7vFnpNKjlSeRyjljddtaZhVH3GAewEQUbihrLhNvFMX4rI
kuGIpNPoBLb9bjrzVWm0pLkCjpF2oJVlHhlFJDDT6iELf7BlSz7EJEJUjdRGAYGv
LsrLYURi2zqMjgJkbuRC3LmkwGl6/tnMlibQotpSnEcyosLA8ySk0k6raUxnbEyD
tH76OvPs/L+HB5YMjJ6J7r8FZpidlLPyl0UcwMdkL2WDLyIgjGGOdTRKnk/HdQ+b
p9Xw7XMIdx5FxFG5xkyvA7iAblYZUpwnFp0AzohIjj9FuDZBitruxSekoB1Yuuyi
EUTjiD0GwRChCe3DAgMBAAGgADANBgkqhkiG9w0BAQsFAAOCAQEAD259nk0geb+C
5VZXz0Q0e1zvcEnLavRkF8L9LX3UOOduFQVaQyIPWc2Ae+VRzc7l67Y75BL82sDs
qCeQmcuWmq3j1AhkHDeV2ihCoo+qDgJbyg7J4YKVFuV/M07MB3BPEbQfeBkUKVQ+
SbpWyxD33Q+fKdALn8DqRBDkg+lEr2wN7ERqtbKsWMScR4CNkIv7UenzfnA/PuKg
boW4yeYbvizVy/dXcqZ6PXqvtUkIoHH/1w2sx3xYFz6EKcOJOa3rWF6oCt6gmSNy
4OAdTEdpsVfuuGJnGdMGXKIIsIaZeG4Hat2EJOZVCT511GDJm4k3JgIzEmvd8v4i
VHizlMtMGg==
-----END CERTIFICATE REQUEST-----

[Robin Alden]

Thank you very much for your continued disclosure.

We (Sectigo) are working on a CPS revision which will clarify the forms of proof of compromise that we accept.

Our customer service staff have to respond to compromise notifications quickly and accurately and we are best able to achieve that by limiting the forms of proof we accept to a set on which our staff have trained.

In the absence of an explicit limitation in our CPS as to the forms of proof we can accept our staff tried their best to respond and escalated it internally for action. The certificate https://crt.sh/?id=2081585376 has been revoked.

I will include all of these details in the incident report which is in preparation.

Regards
Robin Alden
Sectigo Limited

> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org>
> On Behalf Of sandybar497--- via dev-security-policy
> Sent: 07 May 2020 03:27
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Sectigo: Failure to revoke certificate with compromised key
>
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.

>
>
> On Wednesday, May 6, 2020 at 5:50:09 AM UTC+10, Ryan Sleevi wrote:

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy