Hi Rob, These 2 roots are covered by our S/MIME audit. However, these are single purpose roots and CCADB's ALV will fail because it won't take an audit report for S/MIME for a CA that does not have the Email trust bit set. We suspect that as others transition to single purpose and cross-sign with their older multi-purpose roots they will see similar issues, so we've filed this https://bugzilla.mozilla.org/show_bug.cgi?id=1952383 today and are waiting for guidance from the browsers on how to proceed. On Thursday, March 6, 2025 at 8:46:11 AM UTC-7 Rob Stradling wrote:
> 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] <[email protected]> on behalf of dr. Szőke Sándor > <[email protected]> > *Sent:* 06 March 2025 12:02 > *To:* Rob Stradling <[email protected]> > *Cc:* 'CCADB Public' <[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. > Report Suspicious > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/J5K_pWsD!H2YV8oVbc87WZd4ul1bz7hbu6oXBX_x7ppTOQCHbxT8a29kkNbVZfZy_RBjJytpLBfJ8tP1ZCE1SRpj6A22n5eNu3Yd2lujUH304eiqTHMomSsh56cDA_rLG1Z03RdRbCjWwWlSzW66kVvrDeku4C7w272HbGuaidfYfQIJzSPeA8ssoj4k0BhLMCCIm2Ioz9qRESvqG2A$> > > > 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%201%20802%204418> | +36 1 505-4477 > <+36%201%20505%204477> / 488 > *[email protected]* > > microsec.com > > > > *From:* 'Rob Stradling' via CCADB Public <[email protected]> > *Sent:* Wednesday, March 5, 2025 10:04 PM > *To:* CCADB Public <[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-5zSmfNQEmNhJ6VEmWOvHNVUaWETmmv5yTfiSK7Zti9VDUBHQ$>* > 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__;!!J5K_pWsD!xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvHNVUaWETmmv5yTfiSK7Ztjc9_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_pWsD!xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvHNVUaWETmmv5yTfiSK7Ztg91WB1cw$>* > 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=1911335__;!!J5K_pWsD!xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvHNVUaWETmmv5yTfiSK7ZtgVGbVaCg$>* > . > > > > 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=1950574__;!!J5K_pWsD!xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvHNVUaWETmmv5yTfiSK7Zth4Smxn-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=1950574__;!!J5K_pWsD!xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvHNVUaWETmmv5yTfiSK7Zth4Smxn-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!xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-idlcn3-5zSmfNQEmNhJ6VEmWOvHNVUaWETmmv5yTfiSK7ZtioikEVSA$>* > 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]*. > To view this discussion visit > *https://groups.google.com/a/ccadb.org/d/msgid/public/MW4PR17MB47298BAE9940F13E86CB678BAACB2%40MW4PR17MB4729.namprd17.prod.outlook.com > > <https://urldefense.com/v3/__https://groups.google.com/a/ccadb.org/d/msgid/public/MW4PR17MB47298BAE9940F13E86CB678BAACB2*40MW4PR17MB4729.namprd17.prod.outlook.com?utm_medium=email&utm_source=footer__;JQ!!J5K_pWsD!xUO4XRFLAW4H6U-RR1tnUrw8Y4mHsi-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]*. > To view this discussion visit > *https://groups.google.com/a/ccadb.org/d/msgid/public/!%26!AAAAAAAAAAAuAAAAAAAAADQphbWDqFVAuLX8xgdsj74BAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAACI7VDwreqhT5TEHKoQW28nAQAAAAA%3D%40microsec.hu > > <https://urldefense.com/v3/__https://groups.google.com/a/ccadb.org/d/msgid/public/!*26!AAAAAAAAAAAuAAAAAAAAADQphbWDqFVAuLX8xgdsj74BAMO2jhD3dRHOtM0AqgC7tuYAAAAAAA4AABAAAACI7VDwreqhT5TEHKoQW28nAQAAAAA*3D*40microsec.hu?utm_medium=email&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/6e3f84db-064b-4ded-81d8-dddb2af345afn%40ccadb.org.
