RE: Arabtec Holding public key? [Weird Digicert issued cert]
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 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 > On Behalf Of Wayne > Thayer via dev-security-policy > Sent: Friday, April 12, 2019 10:39 AM > To: Jakob Bohm > Cc: mozilla-dev-security-policy > > 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 d
Re: Arabtec Holding public key? [Weird Digicert issued cert]
According to Jeremy (see below), that was not the situation. On 15/04/2019 14:09, Man Ho wrote: I don't think that it's trivial for less-skilled user to obtain the CSR of "DigiCert Global Root G2" certificate and posting it in the request of another certificate, right? On 15-Apr-19 6:57 PM, Jakob Bohm via dev-security-policy wrote: 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). 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
Re: Arabtec Holding public key? [Weird Digicert issued cert]
I don't think that it's trivial for less-skilled user to obtain the CSR of "DigiCert Global Root G2" certificate and posting it in the request of another certificate, right? On 15-Apr-19 6:57 PM, Jakob Bohm via dev-security-policy wrote: > 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 >> On Behalf Of Wayne >> Thayer via dev-security-policy >> Sent: Friday, April 12, 2019 10:39 AM >> To: Jakob Bohm >> Cc: mozilla-dev-security-policy >> >> 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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 On Behalf Of Wayne Thayer via dev-security-policy Sent: Friday, April 12, 2019 10:39 AM To: Jakob Bohm Cc: mozilla-dev-security-policy 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
Re: Arabtec Holding public key? [Weird Digicert issued cert]
On Fri, 12 Apr 2019 16:56:23 + Jeremy Rowley via dev-security-policy 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). Thanks Jeremy I agree that in TLS specifically there's no direct way to leverage these certificates to do anything awful. So for m.d.s.policy's core purpose of caring about Mozilla/ Firefox there's no problem here, and as others have noticed the BRs are silent on this. Though perhaps they should not be. I am not so sure in the general case, it is certainly possible in the very general sense to create scenarios in which something resembling the Confused Deputy problem arises with this sort of certificate, a loose example follows taking inspiration from the work done recently on TLS 1.3 PSK attacks by Drucker and Gueron 1. Trent is a Trusted Third Party, in this case a CA issuing IOT devices certificates tying their identity to a public key. Unfortunately Trent is easily confused as we shall see 2. These IOT devices don't do TLS but have some custom public key protocol using Trent's certificates. One feature in this protcol is the [MUTE] message to tell devices you want nothing further to do with them. 3. Alice, the Archive System, has a cert (Alice,A). Bob, the video surveillance system also has a cert (Bob,B). And finally there's a singing fish toy Carol with a cert (Carol,C) received as a free gift. 4. The makers of Carol trick Trent into issuing (Carol,A) a certificate with Carol's identity but Alice's public key 5. Carol presents Bob with (Carol,A) and annoys Bob with constant nonsense, knowing that in the protocol Bob can reply with a [MUTE] message to make her stop. 6. Bob sends a message to Carol, but using the A public key. Carol can't read this message since she does not know the A private key but she can reasonably guess it's a [MUTE] 7. Carol relays Bob's [MUTE] to Alice. It is encrypted to Alice, and signed by Bob, so Alice will consider this a valid [MUTE] message from Bob. 8. Now the video surveillance footage is not archived, because a toy fish switched it off... it may be very difficult to diagnose that the problem was with Trent, issuing this bogus (Carol,A) cert, as even if suspicion falls on Carol (or Carol's makers) it's far from obvious how they could cause Bob to send Alice a message. The fact that DigiCert's CPS says explicitly that it will check CSRs is a good thing. Not checking them is a bad thing. Is the situation that we need to spell out in the BRs or Mozilla policy every single basically good idea to ensure CAs don't think it's optional and stop doing it? Let's hope not. Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Arabtec Holding public key? [Weird Digicert issued cert]
Unfortunately yes. We plan on updating our CPS and bringing it up with our auditors during this audit, who is on-site next week. From: Wayne Thayer Sent: Friday, April 12, 2019 11:30 AM To: Jeremy Rowley Cc: Jakob Bohm ; mozilla-dev-security-policy Subject: Re: Arabtec Holding public key? [Weird Digicert issued cert] Jeremy: do you consider the fact that DigiCert signed certs without proof of private key possession to have been a violation if its CPS? On Fri, Apr 12, 2019 at 10:04 AM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote: 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 mailto: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 mailto:wtha...@mozilla.com> >; Jakob Bohm mailto:jb-mozi...@wisemo.com> > Cc: mozilla-dev-security-policy mailto: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 mailto: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 mailto:jb-mozi...@wisemo.com> > Cc: mozilla-dev-security-policy mailto: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 <mailto: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'
Re: Arabtec Holding public key? [Weird Digicert issued cert]
Jeremy: do you consider the fact that DigiCert signed certs without proof of private key possession to have been a violation if its CPS? On Fri, Apr 12, 2019 at 10:04 AM Jeremy Rowley wrote: > 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 > On Behalf Of Jeremy Rowley via dev-security-policy > Sent: Friday, April 12, 2019 10:56 AM > To: Wayne Thayer ; Jakob Bohm > 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 > On Behalf Of Wayne Thayer via dev-security-policy > Sent: Friday, April 12, 2019 10:39 AM > To: Jakob Bohm > 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/mozill
RE: Arabtec Holding public key? [Weird Digicert issued cert]
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 On Behalf Of Jeremy Rowley via dev-security-policy Sent: Friday, April 12, 2019 10:56 AM To: Wayne Thayer ; Jakob Bohm Cc: mozilla-dev-security-policy 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 On Behalf Of Wayne Thayer via dev-security-policy Sent: Friday, April 12, 2019 10:39 AM To: Jakob Bohm Cc: mozilla-dev-security-policy 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
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 On Behalf Of Wayne Thayer via dev-security-policy Sent: Friday, April 12, 2019 10:39 AM To: Jakob Bohm Cc: mozilla-dev-security-policy 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
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=8bb593a93be1d0e8a822bb887c547890c3e706aad2dab76254f97fb36b82fc26 > >>> > >>> ... 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/zECd9J3KBW8/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
Re: Arabtec Holding public key? [Weird Digicert issued cert]
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=8bb593a93be1d0e8a822bb887c547890c3e706aad2dab76254f97fb36b82fc26 ... 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/zECd9J3KBW8/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
