Hi Rob,
 
we sent an email to CCADB operator yesterday, and we opened an incident
ticket in Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1952519
 
I feel that the management of doppelganger root certificates is problematic
in CCADB, it would be useful to develop clear rules for this.
 
Kind Regards,
 
Sándor
 
 
From: Rob Stradling <[email protected]> 
Sent: Thursday, March 6, 2025 4:46 PM
To: dr. Szőke Sándor <[email protected]>
Cc: 'CCADB Public' <[email protected]>
Subject: Re: Missing or Inconsistent Disclosure of S/MIME BR Audits
 
Hi Dr. Sándor.
 
> thank you for your efforts to improve the security of the web PKI.
 
You're welcome!  Thank you for your prompt attention and investigation into
this matter.
 
> We do not know how and why, but one of the doppelganger certificates has
been added to CCADB as a separate root as well, and this may be the source
of the problem.

It looks like the doppelganger root certificate was previously present in
the Microsoft root store, since the "Microsoft Status" on
https://ccadb.my.site.com/0018Z00002iKhM2QAK is "Removed".  This is
presumably why a Root Certificate record for this certificate exists in
CCADB.
 
> We contact the CCADB operators and ask them what to do to solve this
issue.
 
Good move.
 
(I'm guessing the solution will be to (1) populate the S/MIME BR audit
details in the Root Certificate record and (2) remove the Intermediate
Certificate record; but let's wait and see if the CCADB operators agree or
have a different preference).
 
  _____  

From: [email protected] <mailto:[email protected]>  <[email protected]
<mailto:[email protected]> > on behalf of dr. Szőke Sándor
<[email protected] <mailto:[email protected]> >
Sent: 06 March 2025 12:02
To: Rob Stradling <[email protected] <mailto:[email protected]> >
Cc: 'CCADB Public' <[email protected] <mailto:[email protected]> >
Subject: RE: Missing or Inconsistent Disclosure of S/MIME BR Audits 
 
This Message Is From an External Sender
This message came from outside your organization.
 
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/J5K_pWsD!H2YV8oVbc87WZd4ul1
bz7hbu6oXBX_x7ppTOQCHbxT8a29kkNbVZfZy_RBjJytpLBfJ8tP1ZCE1SRpj6A22n5eNu3Yd2lu
jUH304eiqTHMomSsh56cDA_rLG1Z03RdRbCjWwWlSzW66kVvrDeku4C7w272HbGuaidfYfQIJzSP
eA8ssoj4k0BhLMCCIm2Ioz9qRESvqG2A$> Report Suspicious
 
Hi Rob,
 
thank you for your efforts to improve the security of the web PKI.
 
We have conducted a quick investigation into the reported S/MIME audit issue
and believe we have found the possible root cause of the issue.
For the problematic "Microsec e-Szigno Root CA 2009" root, Microsec has a
"working" root certificate that is included in several Root Programs.
For different reasons, two doppelganger certificates have been issued for
this root, which are not active and are not directly trusted by any of the
Root Programs.
These two doppelganger certificates have been added to CCADB as subordinate
certificates under the "working" root CA certificate and the audits are
marked "as parents".
Microsec has a total of 3 root certificates for this root entity, but there
are 4 instances in CCADB, as shown in the following table.
We do not know how and why, but one of the doppelganger certificates has
been added to CCADB as a separate root as well, and this may be the source
of the problem.
 
Microsec e-Szigno Root CA 2009

SHA256 hash
Cert Serial Number
CCADB Unique ID
Included in CCADB as
Included in Root Programs

3C5F81FEA5FAB82C64BFA2EAECAFCDE8E077FC8620A7CAE537163DF36EDBF378
00C27E43044E473F19
A000164
root
included

8E8C6EBF77DC73DB3E38E93F4803E62B6B5933BEB51EE4152F68D7AA14426B31
00C27E43044E473F18
A010460
root
not included

8E8C6EBF77DC73DB3E38E93F4803E62B6B5933BEB51EE4152F68D7AA14426B31
00C27E43044E473F18
A004417
subordinate
same as parent

72F9AF2158181BAF16D60C9B4E6F4BD7CA8D2341AD48AFDB67CB4C8332D546F6
00E8849639AB66105A
A006945
subordinate
same as parent
 
 
We contact the CCADB operators and ask them what to do to solve this issue.
 
Kind Regards,
 
Sándor
 
Dr. Sándor SZŐKE
dep. Director of eIDAS Trust Services
 

 
Microsec Ltd.  |  Ángel Sanz Briz Road 13.
Budapest, H-1033 Hungary
Graphisoft Park Southern Area, Building SP3, 3th floor
T: +36 1 802-4418  |   +36 1 505-4477 / 488
 <mailto:[email protected]> [email protected]
microsec.com
 
From: 'Rob Stradling' via CCADB Public <[email protected]
<mailto:[email protected]> >
Sent: Wednesday, March 5, 2025 10:04 PM
To: CCADB Public <[email protected] <mailto:[email protected]> >
Subject: Missing or Inconsistent Disclosure of S/MIME BR Audits
 
Per the Mozilla, Apple, and Microsoft root program policies, all CA Owners
with one or more Root or Intermediate CAs trusted for the issuance of S/MIME
certificates should have completed an S/MIME BR audit by now and disclosed
the audit details on each applicable CCADB record.
 
I recently added tracking to https://crt.sh/mozilla-disclosures
<https://urldefense.com/v3/__https:/crt.sh/mozilla-disclosures__;!!J5K_pWsD!
xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvHNVUaWETmmv5yTfiSK7
Zti9VDUBHQ$>  to flag missing and inconsistent disclosures of S/MIME BR
audits.  Since this crt.sh report is currently flagging issues for a number
of CA Owners, I thought I would share a summary of the findings here.  In my
view, most (if not all) of these issues should be treated as incidents per
https://www.ccadb.org/cas/incident-report
<https://urldefense.com/v3/__https:/www.ccadb.org/cas/incident-report__;!!J5
K_pWsD!xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvHNVUaWETmmv5
yTfiSK7Ztjc9_BCuA$> .
 
CA Owners with Missing S/MIME BR Audit details:
 
GoDaddy:
Several applicable Root Certificate records don't specify any S/MIME BR
audit details.  The WebTrust seals on https://certs.godaddy.com/repository
<https://urldefense.com/v3/__https:/certs.godaddy.com/repository__;!!J5K_pWs
D!xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvHNVUaWETmmv5yTfiS
K7Ztg91WB1cw$>  do not include an S/MIME BR seal.  Has GoDaddy undergone an
S/MIME BR audit?
 
TWCA:
No S/MIME BR audit details have been disclosed on one Root Certificate
record.  This root CA isn't directly trusted for S/MIME, but it counts as
S/MIME-capable because it's cross-certified by a root that is trusted for
S/MIME.  Is ticking "Audits Same as Parent" the required resolution here?
 
DigitalSign - Certificadora Digital, S.A.:
Two root certificates have only the Email trust bit set in NSS, but the
corresponding Root Certificate records in CCADB have no S/MIME BR audit
details disclosed.  Has DigitalSign undergone an S/MIME BR audit?
 
eMudhra:
Two applicable Intermediate Certificate records don't specify any S/MIME BR
audit details.  Is ticking "Audits Same as Parent" the required resolution
here?
 
Entrust:
Two applicable Root Certificate records don't specify any S/MIME BR audit
details.  Although these roots have been distrusted for further issuance of
TLS server certificates, they are still fully trusted for the issuance of
S/MIME certificates.  Has Entrust undergone an S/MIME BR audit?
 
Siemens (externally-operated Sub-CAs under Entrust):
Several applicable Intermediate Certificate records specify no S/MIME BR
audit details.  Has Siemens undergone an S/MIME BR audit?
 
Ministerie van Defensie (externally-operated Sub-CA under PKIoverheid):
One applicable Intermediate Certificate record doesn't specify any S/MIME BR
audit details.  See also
https://bugzilla.mozilla.org/show_bug.cgi?id=1911335
<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=191
1335__;!!J5K_pWsD!xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvH
NVUaWETmmv5yTfiSK7ZtgVGbVaCg$> .
 
LAWtrust:
One applicable Root Certificate record doesn't specify any S/MIME BR audit
details.  Has LAWtrust undergone an S/MIME BR audit?
 
Cybertrust Japan (externally-operated Sub-CA under SECOM Trust Systems):
One applicable Intermediate Certificate record doesn't specify any S/MIME BR
audit details.  See also
https://bugzilla.mozilla.org/show_bug.cgi?id=1950574
<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=195
0574__;!!J5K_pWsD!xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvH
NVUaWETmmv5yTfiSK7Zth4Smxn-g$> .
 
CA Owners with Inconsistent Disclosure of S/MIME BR Audit details:
 
Asseco Data Systems:
One applicable Root Certificate record doesn't specify any S/MIME BR audit
details.  Although this root certificate is not present in root stores, its
signature can be validated by a doppelganger root that is.  (The serial
number of this self-signed root certificate appears in the CRL, but I think
it's questionable as to whether self-signed certificates can actually be
revoked in this manner.  This self-signed root certificate is also listed in
OneCRL, but AIUI OneCRL is only applicable to Firefox's use of TLS server
certificate chains, meaning that it's out of scope for Mozilla's interest in
S/MIME).
 
DigiCert:
Two applicable Root Certificate records don't specify any S/MIME BR audit
details.  These root CAs aren't directly trusted for S/MIME, but they do
inherit S/MIME-capability via cross-certification from other DigiCert roots.
(The CCADB records for the cross-certificates all specify "Audits Same as
Parent", and the corresponding parent records do specify S/MIME BR audit
details).
 
Microsec:
Similar to the Asseco Data Systems case, a doppelganger Root Certificate
record doesn't specify any S/MIME BR audit details.
 
Cybertrust Japan (externally-operated Sub-CA under SECOM Trust Systems):
One applicable Intermediate Certificate record doesn't specify any S/MIME BR
audit details (see above), whereas a doppelganger Intermediate Certificate
record does.  See also https://bugzilla.mozilla.org/show_bug.cgi?id=1950574
<https://urldefense.com/v3/__https:/bugzilla.mozilla.org/show_bug.cgi?id=195
0574__;!!J5K_pWsD!xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvH
NVUaWETmmv5yTfiSK7Zth4Smxn-g$> .
 
Telia:
In two cases, the S/MIME BR audit Statement Date differs between a Root
Certificate record and a corresponding Intermediate Certificate
(cross-certificate) record.
 
apple-disclosures
 
I have also added tracking to https://crt.sh/apple-disclosures
<https://urldefense.com/v3/__https:/crt.sh/apple-disclosures__;!!J5K_pWsD!xU
O4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvHNVUaWETmmv5yTfiSK7Zt
ioikEVSA$>  to flag missing and inconsistent disclosures of S/MIME BR
audits.  This report currently flags issues for some additional CA Owners,
but since crt.sh is not yet tracking all of the intricacies of Apple's root
store metadata there may be some false positives. 
 
--
Rob Stradling
Distinguished Engineer
Sectigo Limited
 
--
You received this message because you are subscribed to the Google Groups
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected] <mailto:[email protected]>
.
To view this discussion visit
https://groups.google.com/a/ccadb.org/d/msgid/public/MW4PR17MB47298BAE9940F1
3E86CB678BAACB2%40MW4PR17MB4729.namprd17.prod.outlook.com
<https://urldefense.com/v3/__https:/groups.google.com/a/ccadb.org/d/msgid/pu
blic/MW4PR17MB47298BAE9940F13E86CB678BAACB2*40MW4PR17MB4729.namprd17.prod.ou
tlook.com?utm_medium=email&utm_source=footer__;JQ!!J5K_pWsD!xUO4XRFLAW4H6U-R
R1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvHNVUaWETmmv5yTfiSK7ZtjXYA21mg$> .
--
You received this message because you are subscribed to the Google Groups
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected] <mailto:[email protected]>
.
To view this discussion visit
https://groups.google.com/a/ccadb.org/d/msgid/public/!%26!AAAAAAAAAAAuAAAAAA
AAADQphbWDqFVAuLX8xgdsj74BAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAACI7VDwreqhT5
TEHKoQW28nAQAAAAA%3D%40microsec.hu
<https://urldefense.com/v3/__https:/groups.google.com/a/ccadb.org/d/msgid/pu
blic/!*26!AAAAAAAAAAAuAAAAAAAAADQphbWDqFVAuLX8xgdsj74BAMO2jhD3dRHOtM0AqgC7tu
YAAAAAAA4AABAAAACI7VDwreqhT5TEHKoQW28nAQAAAAA*3D*40microsec.hu?utm_medium=em
ail&utm_source=footer__;JSUl!!J5K_pWsD!xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3
-5zSmfNQEmNhJ6VEmWOvHNVUaWETmmv5yTfiSK7ZtgbztOtzw$> .

-- 
You received this message because you are subscribed to the Google Groups 
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/00c301db8f6d%240afd6ef0%2420f84cd0%24%40microsec.hu.

Reply via email to