GlobalSign: Failure to revoke certificate with compromised private key within 24 hours
A certificate with a publicly-disclosed private key was reported to GlobalSign for revocation within the BR-mandated 24 hour period, however the revocation took place over 46 hours after the report was sent. Several requests for information I had already provided were made by GlobalSign, however the revocation eventually took place without any further information being required. Communication from GlobalSign then appeared to suggest that the certificate had "already" been revoked, despite timestamps in the CRL indicating otherwise. I believe an incident report for this event is warranted, given that GlobalSign was provided with sufficient information to revoke the certificate in the initial problem report (based on the fact that revocation eventually took place with no further information being provided by myself), but failed to do so within the BR-mandated time period. Excuciatingly detailed timeline follows. 2020-03-06 21:48:53Z E-mail sent to report-ab...@globalsign.com: -8<- Date: Sat, 7 Mar 2020 08:48:53 +1100 From: Matt Palmer To: report-ab...@globalsign.com Subject: Problem Report for certificate(s) with compromised private key One or more certificates issued by your CA are using a private key which has been publicly disclosed. The list of affected certificates can be retrieved from https://crt.sh/?spkisha256=6a02703a7a2ba3f368a2915305383549cf8ada8262422697d62d5ba410e4d93f Included below is a CSR, signed by the compromised private key, demonstrating proof of possession: -BEGIN CERTIFICATE REQUEST- MIIE0TCCArkCAQAwgYsxaTBnBgNVBAMMYFRoZSBrZXkgdGhhdCBzaWduZWQgdGhp cyBDU1IgaGFzIGJlZW4gcHVibGljbHkgZGlzY2xvc2VkLiBJdCBzaG91bGQgbm90 IGJlIHVzZWQgZm9yIGFueSBwdXJwb3NlLjEeMBwGA1UECgwVaHR0cHM6Ly9wd25l ZGtleXMuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2OMM6yti 3q+GhnZsMPYrACVrZWYqn2yz2fH5J6kPONDvHm3P4UgPJb5j0OFUbmng3e41FwWf QhD7UFbiEtH/fCJLnxuhAlCBZkVTwIBIwIYRpBmSp/shtNBJZvHBPgktF78qQBr5 HaX9jZOl/z0rLVw42wnzHlMyyeJNCQzBgRqA+Lcgig/9I2qxQvm3C53868i0EE3k B418D63cEhz6hldoxELt7twoYulwyLk/PXWj/I0qHQZGT1weLD6UXINuxhmcFUDj 4i5V9UqNWhP4LT/QWjNtqE5y1OOT5qtkczjmSd3TS3GCik3o7v2M7JxwME1T/e/z unTqhCarZF3HkrN5MxDB/28HsPaSRUpbxzmIUt+GApuVjNWnRW0awlzp8i5wQnmo x7nNtSSht44DhlWETpPeT3n27LKM64no97aN0NS0LEKc5sFuOcS5sCj5FvsxNm/8 RhqfQkHXjkhZByTPhYvkQZTTA8Gxsh52Pnr0aTKrNz/fNpcJWzlKvbSmQn7i1Nmn z6f9cTB3gW9+DjgSq/XjgVZJdGAWD9k5/i+v8b0zSbpprGNh2gkn39QYmWLlS2eu XhtAhdWAroEBxm5pLA3T50KWcfM1IHsZSHIeneIcR3anUhqnA1vMjZdFdFkX+TCE n/c6cotq/fESE+ieMdc7NjpTn4w2a+10xHECAwEAAaAAMA0GCSqGSIb3DQEBCwUA A4ICAQCnPqJFlaTaNTz0ldS+PepRa8cpf4DXJ/shKBf8ChJ7ivY8+Q6qQWLU4WTM DSChT+5K2Zlr5LRoIBeTsgyl3345agsPI8BKjw1OpRlxgVsMKlKOd6nCSJPw2NDl +Ud+s/LbnZJsIn9nb4fQdF+mC4L6Q1GikCkTfQ1SD8RykVgwojiQFwsdaNRy1U2z uw3QtlYXZ1s/zdgEITBB4x5js1r8+njue3X4hbgmTrnppEpxeaiuKIImLxFCOveo pv6evi9g8mYCZ2hqvLO2RTO3iTSvbDAgbImr6D0Asem1qdCdNPbhiGXj/kxJNNUQ P5hb1KmbcdCLIjvMz0+Z6TkIW0q4MowUpUeKx8Y18Pjt9D+nLN9sRLi8vfjvlnt4 eLENX2156CWMmJQg4n16UjYKaf6dSCvWJYC2TzYJzs+ZEKU71LCkUl/hdj7ZNLtZ o3Z3C892nPZ56LdJES2wBMFgfMV5EWo4MrriFO7yhpkVp3NlOWkWVjIuTPDsm0gK fLVgHQPfgpVR6LT/e2HWISdiogUrACsVFrb5vfehXY2PAewPghkD5Cn3LG6hnXYn hmjgXDwz2dK5ud3ABJT1UxJtn82o3z3okUDISdeioxw43HBhCQ84p3G+JoRq9x6+ 2ncweNmCQQ66tsX386ywKpPQJ4/1DrRsOKdSSy7siwwtR437Rg== -END CERTIFICATE REQUEST- Please revoke all affected certificates within 24 hours, as per the Baseline Requirements. - Matt ->8- 2020-03-06 21:49:04Z E-mail is accepted for delivery by a GlobalSign MX: -8<- Mar 6 21:49:04 minotaur postfix/smtp[26026]: 75BC71857EE: to=, relay=globalsign-com.mail.protection.outlook.com[104.47.93.36]:25, delay=6.8, delays=0.47/0.01/0.9/5.4, dsn=2.6.0, status=sent (250 2.6.0 <20200306214853.kpohtnh5y2m3k...@hezmatt.org> [InternalId=34857954577034, Hostname=HK0PR03MB2755.apcprd03.prod.outlook.com] 10967 bytes in 3.479, 3.078 KB/sec Queued mail for delivery) ->8- 2020-03-06 21:49:15Z Auto-ack e-mail received from GlobalSign: -8<- Dear Matt Palmer, Thank you for reporting this issue to GlobalSign. Case #04076325: "Problem Report for certificate(s) with compromised private key" has been created and a GlobalSign representative will investigate this immediately. If requested you will receive a response from a designated representative as soon as possible. Thank you, Customer Service Team GlobalSign ->8- 2020-03-06 22:08:06Z Human response from GlobalSign: -8<- Hello, Thank you for contacting GlobalSign. We have received your report of certificate abuse. GlobalSign takes these accusations very seriously. We will be opening an investigation and will keep you updated on any advances we make. Sincerely, Akshit Bhambota GlobalSign Support Team ->8- 2020-03-06 22:21:22Z A rather odd form-looking e-mail is sent from GlobalSign: -8<- Hello, Thank you for submitting your report regarding the suspected fraudulent activity or misuse of a GlobalSign certificate. In furtherance of this, we will require additional information to
Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours
Hi Joanna, Thanks for responding. When can this list, or Bugzilla, expect GoDaddy's incident report? Also, for the avoidance of further doubt, can you give an exact timestamp at which GoDaddy considers that evidence of key compromise was "obtained" for this certificate? - Matt On Mon, Mar 09, 2020 at 01:46:17PM -0700, Joanna Fox via dev-security-policy wrote: > Matt, > > Thank you for sharing your experience with our problem reporting mechanism on > this forum. It is due to this that we were able to get to the root of the > issue. Here is some detail into what we saw. > > Yesterday, we launched an investigation which included various members of the > team researching this issue. We took this investigation as far as we could > with the information we had and concluded that the CSR provided, as we read > it, was malformed. We ran this CSR through various tools but were unable to > successfully confirm validity. > > This morning, based on the statements in this forum, we discovered that our > email system had misinterpreted the CSR formatting due to it being pasted in > the body of the email. When we fix Base64 encoding, the CSR verifies. > > Upon this discovery we have initiated revocation to occur within the > guidelines of 24 hours from obtaining evidence that the private key was > compromised. We take key compromises very seriously and recognize the > importance to the industry and health of the ecosystem. > > Lastly, we also noticed that the email you received was malformed, missing > some of the required content for the OpenSSL command. This event has led to > a review of our email system to learn how we can avoid malformed encoding > issues in the future. > > Thank you, > Joanna Fox > GoDaddy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
On Mon, Mar 09, 2020 at 11:48:40AM -0700, Kathleen Wilson via dev-security-policy wrote: > ==Bad== This is a *very* long list of bad things. Based on this list alone I think it would be reasonable for Mozilla to reject this application. I'd like to highlight the things that are practically problematic, based on my recent work attempting to revoke certificates for compromised keys. > * BR section 4.9.3 requires CPS section 1.5.2 to contain instructions for > reporting an issue such as key compromise to the CA. The Microsec CPS’ only > state that questions related to the policy may be reported via the info in > that section, and other email addresses > (“highprioritycertificateproblemrep...@e-szigno.hu”, > “revocat...@e-szigno.hu") are found in other sections of some documents. Section 1.5.2 is where I go looking for contact information to revoke a certificate. If it's not there... I'm outta luck. > Section 4.9.5 then states that revocation requests are only accepted at the > address listed in section 1.2, but there is no email address in this > section. I like their clarity that they don't accept revocation requests to other addresses, but then not listing any valid addresses does make it tricky. Especially since the previous paragraph gives an e-mail address to contact. On that subject: s4.9.5 of the DV/OV CPS states: > In case of applications sent by electronic mail, the time of arrival is > when the email is received to the dedicated email address > revocat...@e-szigno.hu on the server of the Trust Service Provider. > Emails arriving out of office hours are considered as arrived at the > beginning of the next business day. I don't believe this is in alignment with the BRs, Mozilla Policy, or general expectations around the availability of a CA. Most of the CPSes I've dug into recently make mention of maintaining "24x7x365" availability for accepting and processing problem reports (and, to be fair, I do often get responses from CAs at all hours). "Next business day" processing is woefully inadequate. Rolling back to the beginning of s4.9 of the DV/OV CPS, let's go through it in order. s4.9: > The usage of the private key belonging to the revoked Certificate shall be > eliminated immediately. If possible, the private key belonging to the > revoked Certificate shall be destroyed immediately after revocation. This is a bit odd to see in a CPS. I am assuming there is something in the subscriber agreement that makes this binding on a subscriber. In any event, I, personally, would consider any issuance of a new certificate using the same private key as a revoked certificate to be misissuance (I don't know if Mozilla would feel the same way). s4.9.2 does not allow me, as an Internet Rando who happens to have an unhealthy fascination with collecting published private keys, from requesting revocation. The CPS really must not dissuade third parties from reporting problems with certificates, IMO. s4.9.3, subsection "High-Priority Certificate Problem Report", does not define what constitutes a "high priority" report, but intimates that it involves requests where law enforcement may need to become involved. If you follow enough links, you get to a page that suggests that key compromise may be considered a "high priority" report, however were I to be looking at this CPS to find a way to report a key compromise, I would not consider using this "high priority" channel, based on the information in this CPS. Based on the above points, and the lengthy set of "bad" points previously identified by Wayne, I would ask Mozilla to reject this application. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy: Failure to revoke key-compromised certificate within 24 hours
Matt, Thank you for sharing your experience with our problem reporting mechanism on this forum. It is due to this that we were able to get to the root of the issue. Here is some detail into what we saw. Yesterday, we launched an investigation which included various members of the team researching this issue. We took this investigation as far as we could with the information we had and concluded that the CSR provided, as we read it, was malformed. We ran this CSR through various tools but were unable to successfully confirm validity. This morning, based on the statements in this forum, we discovered that our email system had misinterpreted the CSR formatting due to it being pasted in the body of the email. When we fix Base64 encoding, the CSR verifies. Upon this discovery we have initiated revocation to occur within the guidelines of 24 hours from obtaining evidence that the private key was compromised. We take key compromises very seriously and recognize the importance to the industry and health of the ecosystem. Lastly, we also noticed that the email you received was malformed, missing some of the required content for the OpenSSL command. This event has led to a review of our email system to learn how we can avoid malformed encoding issues in the future. Thank you, Joanna Fox GoDaddy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ssl.com: Certificate with Debian weak key
On Sun, 8 Mar 2020 10:57:49 +1100 Matt Palmer via dev-security-policy wrote: > > The fingerpint of the claimed Debian weak key was not included in > > our database. > > I think it's worth determining exactly where SSL.com obtained their > fingerprint database of weak keys. The private key in my possession, > which I generated for inclusion in the pwnedkeys.com database, was > obtained by using the script provided in the `openssl-blacklist` > source package, with no special options or modifications. Yes, I would certainly want SSL.com's report to give me confidence that #1 they've identified why they didn't spot this key, were there (many?) other keys which would also have been missed? #2 they now have a complete and accurate list of such keys #3 they went back and did the work to re-check other certificates they've issued for this (these?) extra weak keys and any matches were revoked and the subscriber contacted Depending on the circumstances in #1 there may well be a lesson for other CAs, especially if using a setup which is similar in some way to SSL.com and so this point is very important. There might also be further questions about SSL.com's processes which failed to detect this mistake. This sort of incident is also important because of the impact on the Subscriber. Had this subscriber used a different CA with a complete list they'd have been informed immediately that their chosen key was a problem. Because SSL.com didn't do that in fact this subscriber was potentially vulnerable to active, and in some cases even passive attacks on their TLS services for the period between issuance and discovery. Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
This request is for inclusion of the Microsec e-Szigno Root CA 2017 trust anchor and to EV-enable the currently included Microsec e-Szigno Root CA 2009 trust anchor as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1445364 BR Self Assessment is here: https://bugzilla.mozilla.org/attachment.cgi?id=9036567 Summary of Information Gathered and Verified: https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0274 Root Certificate Download URLs: http://www.e-szigno.hu/rootca2017.crt http://www.e-szigno.hu/rootca2009.crt CP/CPS: eIDAS conform Qualified Certificate for Website Authentication CP (EV): https://static.e-szigno.hu/docs/hr--min--ssl--EN--v2.13.pdf eIDAS conform Qualified Certificate for Website Authentication CPS (EV): https://static.e-szigno.hu/docs/szsz--min--ssl--EN--v2.13.pdf eIDAS conform Certificate for Website Authentication CP (DV, OV): https://static.e-szigno.hu/docs/hr--fok--ssl--EN--v2.13.pdf eIDAS conform Certificate for Website Authentication CPS (DV, OV): https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.13.pdf This request is to include the 2017 root with the websites and email trust bits enabled, and to enable both roots for EV. Test Websites for the 2017 root: Valid: https://eqtlsca2018-valid.e-szigno.hu/ Expired: https://eqtlsca2018-expired.e-szigno.hu/ Revoked: https://eqtlsca2018-revoked.e-szigno.hu/ Test Websites for the 2009 root: Valid: https://qtlsca2018-valid.e-szigno.hu/ Expired: https://qtlsca2018-expired.e-szigno.hu/ Revoked: https://qtlsca2018-revoked.e-szigno.hu/ CRL URLs: http://rootca2017-crl1.e-szigno.hu/rootca2017.crl, http://rootca2017-crl2.e-szigno.hu/rootca2017.crl, http://rootca2017-crl3.e-szigno.hu/rootca2017.crl http://rootca2009-crl1.e-szigno.hu/rootca2009.crl, http://rootca2009-crl2.e-szigno.hu/rootca2009.crl, http://rootca2009-crl3.e-szigno.hu/rootca2009.crl OCSP URLs: http://rootca2017-ocsp1.e-szigno.hu, http://rootca2017-ocsp2.e-szigno.hu, http://rootca2017-ocsp3.e-szigno.hu http://rootca2009-ocsp1.e-szigno.hu, http://rootca2009-ocsp2.e-szigno.hu, http://rootca2009-ocsp3.e-szigno.hu Audit: Annual audits are performed by TÜViT according to the ETSI 319 411 audit criteria. Microsec e-Szigno Root CA 2017: BR: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121302_e-Szigno-Root-CA-2017_V1.1_s.pdf EV: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019061201_Microsec-eSzignoRoot-CA-2017_EV-CAs_s.pdf Microsec e-Szigno Root CA 2009: BR: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121301_Microsec-eSzignoRoot-CA-2009_V1.1_s.pdf EV: https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019121301_Microsec-eSzignoRoot-CA-2009_V1.1_s.pdf Wayne performed the detailed review of the CPs, CPSs, BR Self Assessment, and related information for inclusion of the Microsec e-Szigno Root CA 2017 and the EV-enablement of the Microsec e-Szigno Root CA 2009 roots that are being tracked in this bug and he had the following comments: ==Meh== * The subordinate CA certificates for this root were created in 2017 and 2018. None of those intended for serverAuth are constrained by EKU. Mozilla began requiring this in 2019. * Microsec issued two certificates in 2018 with 3-year validity periods [1]. * There are roughly 20 policy documents for this hierarchy [2]. It is quite challenging to determine which documents apply to which types of certificates. The upcoming version of Mozilla policy states that “CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.” * CP section 1.3.2 permits 3rd party RAs, but in their BR Self-Assessment, Microsec states that “The Trust Service Provider do not apply third parties for RA activities.” * CPS section 4.9.5 provides a detailed explanation of the revocation process but fails to mention the required preliminary report to the Subscriber and the entity who filed the Certificate Problem Report. * CPS section 4.9.1 contains a section titled “Reasons for Revoking a Subordinate CA Certificate operated by another CA” but in their BR Self-assessment, Microsec states that “All Subordinate CA-s under the Microsec roots are operated by Microsec.” ==Bad== * I was unable to locate the description of email address validation practices required by Mozilla policy section 2.2. Microsec published new CPS version adding section 3.2.7 to resolve this issue. * Microsec recently issued what appears to be two certificate used for testing that violate the BRs [3][4]. They are now expired. * CCADB currently lists 9 audit letter validation failures for Microsec. * The root contains subject L and organizationIdentifier fields which are arguably in violation of BR 7.1.4.3 [5]. Some, if not all, of the subCAs also exhibit this issue. * BR section 4.9.3 requires CPS section 1.5.2 to contain instructions for reporting an issue
Re: ssl.com: Certificate with Debian weak key
On 07/03/2020 23:57, Matt Palmer via dev-security-policy wrote: As further independent confirmation, the crt.sh page for the certificate shows that crt.sh *also* identifies the certificate as having a Debian weak key. My understanding is that crt.sh uses a database of keys that was independently generated by the operator of the crt.sh service. For the crt.sh check, I augmented Debian's original blacklists with some other blacklists I generated ~12yrs ago for a few less common key sizes [1]. See also [2]. [1] https://secure.sectigo.com/debian_weak_keys/ [2] https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg10060.html - Matt -- Rob Stradling Senior Research & Development Scientist Email: r...@sectigo.com ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
