A possibility. They could have pasted something in the root chain. Note that the required handshake would have caught that if it'd been implemented. Overall it doesn't matter too much if was malicious or innocent, the cert holder can't do anything without the private key.
-----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Jakob Bohm via dev-security-policy Sent: Monday, April 15, 2019 4:58 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Arabtec Holding public key? [Weird Digicert issued cert] Thanks for the explanation. Is it possible that a significant percentage of less-skilled users simply pasted in the wrong certificates by mistake, then wondered why their new certificates newer worked? Pasting in the wrong certificate from an installed certificate chain or semi-related support page doesn't seem an unlikely user error with that design. On 12/04/2019 18:56, Jeremy Rowley wrote: > 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=8bb593a93be1d0e8a822bb887c547890c3e706aad2 >> d >> 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/zECd9J3KB >> W >> 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
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
