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]> 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 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. 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 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. 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. 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. 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 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/MW4PR17MB47298BAE9940F13E86CB678BAACB2%40MW4PR17MB4729.namprd17.prod.outlook.com <https://groups.google.com/a/ccadb.org/d/msgid/public/MW4PR17MB47298BAE9940F13E86CB678BAACB2%40MW4PR17MB4729.namprd17.prod.outlook.com?utm_medium=email&utm_source=footer> . -- 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.
