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=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
