Audit Upload Conflict in CCADB for Cross-Sign Roots
Categories
(CA Program :: Common CA Database, enhancement)
Tracking
(Not tracked)
People
(Reporter: dcbugzillaresponse, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36
Expected results:
These 2 roots aren't directly trusted for S/MIME, but they are cross-signed with roots that are. Because of the cross-signing, the 2 roots in question are included in our WebTrust S/MIME BR audit report. However, The 2 roots in question do not issue S/MIME certificates and CCADB won't allow an audit to be associated with a trust bit that differs from what the root is actually trusted for. How would you like us to proceed?
|
||
Comment 1•8 months ago
|
||
Have you tried adding the WebTrust S/MIME BR audit report just to the CCADB record for the cross-signed CA certificates (as the CCADB treats these as Intermediate CA certificates)?
To which two cross-signed CA certificates do you refer?
The following cross-signed CAs share the same SPKI (6a97b51c8219e93e5dec64bad5806cdeb0f8355be47e757010b702456e01aafd) and are cross-signed with the root listed below. However, this root is a single-purpose root, not intended or trusted for S/MIME. As a result, we did not upload our WebTrust S/MIME audit report for it in CCADB:
Cross-Signed CAs:
- https://crt.sh/?sha256=1ba02ff4a2562bbe6b799563990c88cc50e1182395719a4eaa803976e2f50860
- https://crt.sh/?sha256=a4bcda32d49cdf05f0cdd085e73c3a2e67880bd48579fed4df5940df76a076d7
- https://crt.sh/?sha256=048e39bbb6b15ef83525f163192cea0df21d3ffabafab7c63909fb1553ee4966
- https://crt.sh/?sha256=1c8c70b263cb13a9e6ee3f097a9673194cc9d686bc14a72c8cdc705f2c0e68a7
- https://crt.sh/?sha256=b9d53f235c5fa8c92eb31dcfcadf4959b34a32af36aca1ea10f07d6551c398a5
Cross-Signed With Root:
DigiCert TLS RSA4096 Root G5 https://crt.sh/?q=371A00DC0533B3721A7EEB40E8419E70799D2B0A0F2C1D80693165F7CEC4AD75
Similarly, the following cross-signed CA shares the same SPKI (a02fafa192c8cb81cb1341554f9c05b71cca2a890b0d1298d683647c961efbdf) and is cross-signed with another root that also does not have an S/MIME audit uploaded in CCADB because it is not trusted for S/MIME:
Cross-Signed CA:
Cross-Signed With Root:
DigiCert TLS ECC P384 Root G5 https://crt.sh/?q=018E13F0772532CF809BD1B17281867283FC48C6E13BE9C69812854A490C1B05
As noted before, the CAs were under S/MIME audit but have not issued S/MIME.
|
||
Comment 3•7 months ago
|
||
In the description it's stated: "However, The 2 roots in question do not issue S/MIME certificates and CCADB won't allow an audit to be associated with a trust bit that differs from what the root is actually trusted for."
Can you elaborate on what is meant by "[...] CCADB won't allow an audit to be associated with a trust bit that differs from what the root is actually trusted for."?
Our interpretation of CCADB policy, particularly for passing the ALV tool (https://www.ccadb.org/cas/alv), is that all CAs (including self-signed certificates) must be associated with the correct audit reports based on the trust bit.
The "DigiCert TLS ECC P384 Root G5" and "DigiCert TLS RSA4096 Root G5" self-signed certificates are single-purpose roots, intended only for TLS issuance.
Initially, we uploaded all audit statements to all our public self-signed certificates, intending to cover all audits. However, the ALV scan returned an error. Unfortunately, we didn’t capture a screenshot or the exact error message.
To resolve the issue, we removed some audit statements from some of the roots and only aligned them with the corresponding trust bits. For example: "DigiCert TLS ECC P384 Root G5" with the TLS BR audit and "DigiCert SMIME ECC P384 Root G5" to the S/MIME BR audit.
We opened case 00002292 on 03/07/2025 in an attempt to recreate the error, but it actually allowed us to assign S/MIME BR audit statement to our 2 TLS single-purpose roots.
Given our shift toward single-purpose roots, we’d like guidance on the correct approach:
- Should we upload our audits to all our roots, considering they are cross-signed by older multi-purpose roots? While they are not technically being used for all purposes, they are still “technically” trusted by Root Stores for everything.
If so, then should CCADB update its trust bit logic to account for certificates that inherit other capability via cross-certification to align with https://crt.sh/mozilla-disclosures current logic because they share an SPKI and we'll include the applicable audit statements per the new updated Derived Trust Bits field?
- Should we structure roots in a way that implies they are strictly single-purpose, and only upload the audit statements for what they are intended to issue?
Could you clarify how you want us to proceed?
Currently our root certificate's SHA-256 fingerprints are listed in all of our audit statements. Just need guidance on how the browsers want it to show in CCADB.
|
||
Comment 5•7 months ago
|
||
I think that given the cross-certificate https://crt.sh/?sha256=d92e93252eabca950870b94331990963a2dd5db96d833c82b08e41afd1719178 does not have an EKU extension, it is unrestricted and the root https://crt.sh/?q=018E13F0772532CF809BD1B17281867283FC48C6E13BE9C69812854A490C1B05 needs to be S/MIME audited. The root https://crt.sh/?q=018E13F0772532CF809BD1B17281867283FC48C6E13BE9C69812854A490C1B05 is multi-purpose and needs to be transitioned to a dedicated root according to Mozilla and Chrome policies by either removing the new root or revoking the cross-certificate (and possibly replacing it with one that has a restricted EKU).
In response to comment 5
We asked the Chrome team, in reference to their recently released policy v1.6 and cross-signing of a new TLS only root with an existing multi-purpose root, "Is the expectation that the signing CA would also need to be TLS only?"
Chrome's answer:
Assuming you are referencing a combination of Section 3.1.2 and Section 3.2.2 of the Chrome Root Program Policy - no, the CA issuing the cross-certificate does not need to be dedicated to TLS.
If the CA represented as the subject of the cross-certificate has its own self-signed root certificate included in the Chrome Root Store, Chrome clients relying on the Chrome Root Store will stop validation at that self-signed root certificate. Despite the existence of the cross-certificate from a “multi-purpose” root, that “subordinate” hierarchy is still considered as being dedicated to TLS.
While the issuer’s certificate will eventually be removed from the Chrome Root Store to align with Section 3.1.3 (Root CA Term-Limit) or Section 3.2.2 (PKI Hierarchies included in the Chrome Root Store), there are no such restrictions placed on root certificates not trusted by default in Chrome. This is, again, because Chrome will stop certificate path building at the root certificate included in the Chrome Root Store.
This answer does not directly address the CCADB audit question, however we think that it does shed some light on the question. As we all transition to single purpose roots all of these will necessarily be cross-signed by existing multi-purpose roots. We do not think it is productive to have these single purpose roots audited for purposes for which they are not intended, and will not be used. If neither the single-purpose root itself, nor the cross-signed version of it is explicitly covered by the audit for the unintended purpose, i.e. a TLS root not audited for S/MIME, ends up with S/MIME certificates issued beneath that hierarchy, that would be a violation of Chrome policy, and therefore an incident, and could end in distrust of that hierarchy by Chrome. In short, we feel there are mechanisms of control already in place to address this without requiring an audit of a root certificate for a purpose for which it is not intended.
|
|
||
Comment 7•7 months ago
|
||
I agree that after the old root is "removed from the Chrome Root Store to align with [...] Section 3.2.2" (and after similar requirements in other browser root programs are met) then the cross-certificate will become irrelevant and the new root will from that point in time forward no longer need to be S/MIME audited. But I still think the S/MIME audit is required until that time, and if CCADB does not allow you to attach that audit, then that sounds like a bug in CCADB.
|
||
Comment 8•7 months ago
|
||
Responding to Comment 4:
The "DigiCert TLS ECC P384 Root G5" and "DigiCert TLS RSA4096 Root G5" self-signed certificates are single-purpose roots, intended only for TLS issuance.
Initially, we uploaded all audit statements to all our public self-signed certificates, intending to cover all audits. However, the ALV scan returned an error. Unfortunately, we didn’t capture a screenshot or the exact error message.
CCADB Case #00002121 appears to be the most recent audit-related data sync to the CCADB with those two root certificates included. Viewing the ALV Results Summary within the Case itself we can see that there were errors in the audit statements:
- Failed to validate EKU 'Server Authentication' because the standard names and standard policies are not found in the audit letters (case insensitive): "WebTrust Principles and Criteria for Certification Authorities - SSL Baseline with Network Security, v2.7"; "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security, v2.7"; "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline, v2.8"; "WebTrust Principles and Criteria for Certification Authorities - SSL Baseline, v2.8"
- Failed to validate EKU 'ServerAuthenticationEV' because the standard names and standard policies are not found in the audit letters (case insensitive): "WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL, v1.8"; "WebTrust Principles and Criteria for Certification Authorities - Extended Validation SSL, v1.8"
The TLS BR Audit provided by DigiCert included: “WebTrust Principles and Criteria for Certification Authorities - SSL Baseline - Version 2.8”, which does not match the labeling included in the WebTrust Illustrative Reports, which ALV is configured against.
The TLS EVG Audit provided by DigiCert included: “WebTrust Principles and Criteria for Certification Authorities - Extended Validation SSL - Version 1.8”, which also does not match the criteria labeling in the WebTrust Illustrative Reports.
It’s not clear if Case #00002121 is referencing the ALV error DigiCert is referring to, but specific to that Case, at the time of reviewing its ALV errors, these could have been corrected with an update to the criteria listed in the Audit Reports. Regardless, these ALV errors do not stop an Audit Report from being associated with a root record, which is why we were trying to understand what was meant by the statement: “[...] CCADB won't allow an audit to be associated with a trust bit that differs from what the root is actually trusted for."
To resolve the issue, we removed some audit statements from some of the roots and only aligned them with the corresponding trust bits. For example: "DigiCert TLS ECC P384 Root G5" with the TLS BR audit and "DigiCert SMIME ECC P384 Root G5" to the S/MIME BR audit.
We opened case 00002292 on 03/07/2025 in an attempt to recreate the error, but it actually allowed us to assign S/MIME BR audit statement to our 2 TLS single-purpose roots.
Correct, ALV does not “stop” a CA Owner from associating any type of Audit Report with a root record in the CCADB. Rather, ALV will present a “Failed to validate EKU [...]” error when it is presented with an Audit Report and it cannot find the applicable audit criteria that matches the relevant trust bit for all root stores.
Regarding the request for guidance, the CCADB Steering Committee is currently discussing and plans to provide clarifying language related to the recent policy and audit disclosure incidents. We expect this will be shared on public@ccadb.org in the coming weeks, and will welcome the community’s feedback. Meanwhile, including certificates in the audit statements for which they are transitively capable of issuing seems most appropriate.
Description
•