Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours
On Thursday, May 21, 2020 at 12:33:25 PM UTC+10, Matt Palmer wrote: > On Tue, May 19, 2020 at 07:33:00PM -0700, sandybar497--- via > dev-security-policy wrote: > > Here are the original headers (omitting my email) > > > > *** > > > > MIME-Version: 1.0 > > Date: Thu, 7 May 2020 12:07:07 + > > Message-ID: > > > > Subject: Certificate Problem Report - compromised key > > From: sandy > [...] > > https://crt.sh/?spkisha256=e92984ace6f80c75b092df972962f2d3f1365ba08c8bbf9b98cdf3aec20d2d2d > > crt.sh sez: > > Revoked (cessationOfOperation)2020-05-08 16:55:17 UTC > > Got to say, that definitely does look like over 24 hours from e-mail to > revocation. Unfortunately, because you're using gmail, it's tricky to be > able to demonstrate when GoDaddy *actually* received the e-mail -- I don't > know of a way to get at the MTA logs to show when it was delivered to the > remote MTA. > > I'd be curious to hear from GoDaddy as to why the revocation reason here is > marked as "cessationOfOperation", rather than "keyCompromise". That > seems... fishy. > > > Content-Type: application/octet-stream; > > name="e92984ace6f80c75b092df972962f2d3f1365ba08c8bbf9b98cdf3aec20d2d2d.pem" > > Content-Disposition: attachment; > > filename="e92984ace6f80c75b092df972962f2d3f1365ba08c8bbf9b98cdf3aec20d2d2d.pem" > > Content-Transfer-Encoding: base64 > > X-Attachment-Id: f_k9wq5sjj0 > > Content-ID: > > Somewhere along the line this got lost. It'd be good to have a copy of it, > for completeness. Since it's in PEM format, you can include it in the body > of an e-mail -- the Mozilla lists are a bit finicky with attachments. > > - Matt I had received a auto-confirmation email from GoDaddy [donotre...@secureserver.net] just one minute after sending my report, the email reply contained case incident id 41854028. Here is a copy of the evidence of compromise sent along with my report (PEM encoded CSR signed from original private key). -BEGIN CERTIFICATE REQUEST- MIICozCCAYsCAQAwXjEYMBYGA1UECgwPQ29tcHJvbWlzZWQgS2V5MUIwQAYDVQQD DDlUaGUga2V5IHRoYXQgc2lnbmVkIHRoaXMgQ1NSIGhhcyBiZWVuIHB1YmxpY2x5 IGRpc2Nsb3NlZC4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDuGNUD DTHpFfAEJj5h9bDHitmui7uJGaVybhxYzdoEvxzeNAhBESQHMfRGyhr2cvHeWlfX G8j1ZjimEEdzF1E14Jqx6duWYyowe4Crc3lFZduisw149ASzwu4A6CDR00zyeb7L xpnthpvSSGzJ8iMZEEC4odsMxOlO0yoEwd7ketlybn6jLNpUIMii/bolbLvY9bMg 5wPMTVyrhLoum+KP+DSP7TuZx41LAeBjhRaYZAXHtrcQAjKIJ+6YjKv/uYdDREKq dw2accMGrsWcSKM/bKuA+l/8+Pye/aMnSo4b7dNzILWGkJC0Ipdg99bkPtx/bWTX NXZfe+EcsQdJK5rNAgMBAAGgADANBgkqhkiG9w0BAQsFAAOCAQEAKYleYx/U6n2v Xai5ckvujoodT5rrINzjI/wuohioys0M8keN5Iq9zbcfX1orHPBhG8+c1pFTzmjh TNhAyz/aur3LqXJ8wijZIDky27WFvjw98jQB6n6Di+LHWHFbFmwz/mHwGIDDqo7c Oy8yG0gXOPOnMwL7VDctgu7/Kk/JX8mcWLbISyCr2CnljOH4nQOEz3j3+MhLZPg7 NcQSq52oiGCPWAEnQ4aJI7vdhY8TWab82sLDO6qy61wek4hp7z1nVctpJkQvBORi F76ayXlgL4G6oCG12VVloK52Ti8kk15HB6YFhD/1mz0fUyOTe/PzedOBaPhiAvv2 FPDcLgBXlg== -END CERTIFICATE REQUEST- Requesting GoDaddy to provide an incident report for this matter. - sandy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours
On Wednesday, May 20, 2020 at 3:03:01 AM UTC+10, Ryan Sleevi wrote: > On Tue, May 19, 2020 at 12:38 PM sandybar497--- via > dev-security-policy wrote: > > I actually submitted this post 6 days ago and was only just approved > > today.. is there a lack of resources approving blog posts? just don't see > > how it's helpful when posts show up so late. > > It looks like you may be posting through Google Groups, which can > cause moderation delays if you're not signed up through > https://lists.mozilla.org/listinfo/dev-security-policy (Groups is > largely Archives, with some mirroring for posting that can have > hiccups, as you can see) > > Certainly, you can always report issues through Bugzilla, as noted at > https://wiki.mozilla.org/CA/Incident_Dashboard , which doesn't have > the same moderation queue. > > > As noted, I sampled the OCSP responder well after 24 hours and the cert had > > not been revoked yet. I don't have a signed copy to share as i didn't save > > it but I don't think it's necessary since it still took GoDaddy over 24 > > hours to revoke. > > Not trying to suggest it's not the case, but these statements alone > aren't necessarily enough to demonstrate non-compliance. Signed > responses or other evidence are useful, especially when things are "on > the cusp" > > > If you compare report timestamp with ocsp timestamp the difference is > > approximately 28hrs and 48mins. > > Can you provide the original message with headers? Either to this or > as an attachment to Bugzilla? Here are the original headers (omitting my email) *** MIME-Version: 1.0 Date: Thu, 7 May 2020 12:07:07 + Message-ID: Subject: Certificate Problem Report - compromised key From: sandy To: practi...@starfieldtech.com Content-Type: multipart/mixed; boundary="92dbd705a50db8c4" --92dbd705a50db8c4 Content-Type: multipart/alternative; boundary="92dbd505a50db8c2" --92dbd505a50db8c2 Content-Type: text/plain; charset="UTF-8" Hello, Request you revoke the all certificate associated with this compromised key. https://crt.sh/?spkisha256=e92984ace6f80c75b092df972962f2d3f1365ba08c8bbf9b98cdf3aec20d2d2d Attached is a valid CSR produced from the original key as evidence of compromise. The CSR is referenced with the spki sha256 fingerprint as the filename. Per cab-forum guidelines, the cert should be revoked within 24 hours. - Sandy --92dbd505a50db8c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello,Request you revoke the all certificate assoc= iated with this compromised=C2=A0key.=C2=A0=C2=A0https://crt.sh/?spkisha256=3De92984ace6f80c75b092df972962f2d3f= 1365ba08c8bbf9b98cdf3aec20d2d2d=C2=A0=C2=A0Attached is a valid = CSR produced from the original key as evidence of compromise. The CSR is re= ferenced with the spki sha256 fingerprint as the filename.Per cab-f= orum guidelines, the cert should be revoked within 24 hours.- Sandy= --92dbd505a50db8c2-- --92dbd705a50db8c4 Content-Type: application/octet-stream; name="e92984ace6f80c75b092df972962f2d3f1365ba08c8bbf9b98cdf3aec20d2d2d.pem" Content-Disposition: attachment; filename="e92984ace6f80c75b092df972962f2d3f1365ba08c8bbf9b98cdf3aec20d2d2d.pem" Content-Transfer-Encoding: base64 X-Attachment-Id: f_k9wq5sjj0 Content-ID: --92dbd705a50db8c4-- *** - sandy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke certificate with compromised key within 24 hours
On Friday, May 15, 2020 at 7:30:45 AM UTC+10, Ryan Sleevi wrote: > Do you have a copy of the OCSP response? > > With such issues, we may need signed artifacts to demonstrate > non-compliance. For example, it shows as revoked via both OCSP and CRL > for me. > > On Thu, May 14, 2020 at 4:32 PM sandybar497--- via dev-security-policy > wrote: > > > > On 7 May 2020 at 12:07:07 PM UTC I reported a certificate to GoDaddy at > > practi...@starfieldtech.com as having its private key compromised. > > > > I received the automated acknowledgement confirmation, however, as of > > 2020-05-09 03:39:36 UTC (well after 24 hours), OCSP still shows the > > certificate as being "Good" > > > > The unrevoked certificate is https://crt.sh/?id=2366734355 > > > > I believe this is a breach of the CA-BR [4.9.1.1. Reasons for Revoking a > > Subscriber Certificate] - > > > > "The CA SHALL revoke a Certificate within 24 hours if one or more of the > > following occurs""The CA obtains evidence that the Subscriber's Private > > Key corresponding to the Public Key in the Certificate suffered a Key > > Compromise" > > > > I would like to request GoDaddy revoke the certificate and provide an > > incident report on this matter. > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy I actually submitted this post 6 days ago and was only just approved today.. is there a lack of resources approving blog posts? just don't see how it's helpful when posts show up so late. As noted, I sampled the OCSP responder well after 24 hours and the cert had not been revoked yet. I don't have a signed copy to share as i didn't save it but I don't think it's necessary since it still took GoDaddy over 24 hours to revoke. If you compare report timestamp with ocsp timestamp the difference is approximately 28hrs and 48mins. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Sectigo: Failure to revoke certificate with compromised key
On Wednesday, May 6, 2020 at 5:50:09 AM UTC+10, Ryan Sleevi wrote: > On Tue, May 5, 2020 at 12:35 PM sandybar497--- via dev-security-policy > wrote: > > > > I submitted a compromised key report to Sectigo [ssl_ab...@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. > > 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 :) 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- ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
GoDaddy: Failure to revoke certificate with compromised key within 24 hours
On 7 May 2020 at 12:07:07 PM UTC I reported a certificate to GoDaddy at practi...@starfieldtech.com as having its private key compromised. I received the automated acknowledgement confirmation, however, as of 2020-05-09 03:39:36 UTC (well after 24 hours), OCSP still shows the certificate as being "Good" The unrevoked certificate is https://crt.sh/?id=2366734355 I believe this is a breach of the CA-BR [4.9.1.1. Reasons for Revoking a Subscriber Certificate] - "The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs""The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise" I would like to request GoDaddy revoke the certificate and provide an incident report on this matter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Sectigo: Failure to revoke certificate with compromised key
I submitted a compromised key report to Sectigo [ssl_ab...@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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
