The net result were some people created private certs with our root cert public key. We signed new certs using that public key after verifying domain control. We saw the process happen a few times but didn't worry about it too much as the requesters didn't control the private key. We ended up shutting off the no-CSR path because we figured the issuance of these certs created a potential PR concern, even if there isn't a real security risk.
-----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Jeremy Rowley via dev-security-policy Sent: Friday, April 12, 2019 10:56 AM To: Wayne Thayer <wtha...@mozilla.com>; Jakob Bohm <jb-mozi...@wisemo.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: RE: Arabtec Holding public key? [Weird Digicert issued cert] I don't mind filling in details. We have a system that permits creation of certificates without a CSR that works by extracting the key from an existing cert, validating the domain/org information, and creating a new certificate based on the contents of the old certificate. The system was supposed to do a handshake with a server hosting the existing certificate as a form of checking control over the private key, but that was never implemented, slated for a phase 2 that never came. We've since disabled that system, although we didn't file any incident report (for the reasons discussed so far). -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Wayne Thayer via dev-security-policy Sent: Friday, April 12, 2019 10:39 AM To: Jakob Bohm <jb-mozi...@wisemo.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Arabtec Holding public key? [Weird Digicert issued cert] It's not clear that there is anything for DigiCert to respond to. Are we asserting that the existence of this Arabtec certificate is proof that DigiCert violated section 3.2.1 of their CPS? - Wayne On Thu, Apr 11, 2019 at 6:57 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 11/04/2019 04:47, Santhan Raj wrote: > > On Wednesday, April 10, 2019 at 5:53:45 PM UTC-7, Corey Bonnell wrote: > >> On Wednesday, April 10, 2019 at 7:41:33 PM UTC-4, Nick Lamb wrote: > >>> (Resending after I typo'd the ML address) > >>> > >>> At the risk of further embarrassing myself in the same week, while > >>> working further on mimicking Firefox trust decisions I found this > >>> pre-certificate for Arabtec Holding PJSC: > >>> > >>> https://crt.sh/?id=926433948 > >>> > >>> Now there's nothing especially strange about this certificate, > >>> except that its RSA public key is shared with several other > >>> certificates > >>> > >>> > https://crt.sh/?spkisha256=8bb593a93be1d0e8a822bb887c547890c3e706aad2d > ab76254f97fb36b82fc26 > >>> > >>> ... such as the DigiCert Global Root G2: > >>> > >>> https://crt.sh/?caid=5885 > >>> > >>> > >>> I would like to understand what happened here. Maybe I have once > >>> again made a terrible mistake, but if not surely this means either > >>> that the Issuing authority was fooled into issuing for a key the > >>> subscriber doesn't actually have or worse, this Arabtec Holding > >>> outfit has the private keys for DigiCert's Global Root G2 > >>> > >>> Nick. > >> > >> AFAIK there's no requirement in the BRs or Mozilla Root Policy for > >> CAs > to actually verify that the Applicant actually is in possession of the > corresponding private key for public keys included in CSRs (i.e., > check the signature on the CSR), so the most likely explanation is > that the CA in question did not check the signature on the > Applicant-submitted CSR and summarily embedded the supplied public key > in the certificate (assuming Digicert's CA infrastructure wasn't > compromised, but I think that's highly unlikely). > >> > >> A very similar situation was brought up on the list before, but > >> with > WoSign as the issuing CA: > https://groups.google.com/d/msg/mozilla.dev.security.policy/zECd9J3KBW > 8/OlK44lmGCAAJ > >> > > > > While not a BR requirement, the CA's CPS does stipulate validating > possession of private key in section 3.2.1 (looking at the change > history, it appears this stipulation existed during the cert > issuance). So something else must have happened here. > > > > Except for the Arabtec cert, the other certs looks like cross-sign > > for > the Digicert root. > > > > Why still no response from Digicert? Has this been reported to them > directly? > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This > public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
