|
|
| (18 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| The [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#4-common-ca-database Common CA Database (CCADB)] uses an Audit Letter Validation (ALV) tool to automatically parse and validate audit statements. This system eliminates manual processing, but it requires audit statements to follow some basic rules in order to function properly.
| | #REDIRECT [[CA/Audit_Statements]] |
| * [https://www.ccadb.org/policy#51-audit-statement-content Audit Statement Requirements and Format Rules] - If an audit statement fails to meet any of these requirements, the CA will be asked to work with their auditor to provide an audit statement that passes ALV.
| |
| | |
| = Root Certificates =
| |
| CAs are required to update the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits audit], [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#33-cps-and-cpses CP, CPS] and test website information for their certificate hierarchies at least annually. To provide this information for root certificates, [https://www.ccadb.org/cas/updates#audit-case-workflow create one Audit Case] in the CCADB for a particular set of audits (e.g. Standard Audit, BR audit, EV Audit). Then create a set of corresponding Root Cases, one per root certificate, to tell the CCADB which Root Certificate records the audit statements in that Audit Case apply to.
| |
| * [https://www.ccadb.org/cas/updates#audit-case-workflow Audit Case Work Flow]
| |
| * [https://www.ccadb.org/cas/updates#instructions Detailed Instructions]
| |
| ** [https://www.ccadb.org/cas/updates#information-required Information Required to create an Audit Case]
| |
| * [https://www.ccadb.org/cas/updates#test-preliminary-audit-statements Run ALV on Preliminary Audit Statements]
| |
| | |
| = Intermediate Certificates =
| |
| Subordinate CAs who operate non-[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#531-technically-constrained technically-constrained] intermediate certificates have the keys to the internet just as much as the [[CA/Included_CAs|CAs who have root certificates directly included in Mozilla's root store]]. Meaning that such subordinate CAs can also issue TLS certificates for any website or domain, so it is imperative that the same rules are being followed by all subordinate CAs operating non-[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#531-technically-constrained technically-constrained] intermediate certificates. There are currently about 150 [[CA/Included_Certificates|root certificates in Mozilla's root store]] , which leads to about 2,500 [[CA/Intermediate_Certificates|intermediate certificates]] that are trusted by Mozilla's root store. To help enforce the rules at the intermediate certificate level, Mozilla requires disclosure of non-[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#531-technically-constrained technically-constrained] intermediate certificates in the CCADB, which automatically runs ALV on them and reports the results to CAs and root store operators in their CCADB home page.
| |
| * [https://groups.google.com/d/msg/mozilla.dev.security.policy/M7NGwCh14DI/8QB-G-CUBwAJ Progress towards enforcement at intermediate certificate level]
| |
| | |
| CAs are required to update the [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits audit] and [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#33-cps-and-cpses CP/CPS] for their non-[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#531-technically-constrained technically-constrained] intermediate certificates chaining to root certs included in Mozilla's program at least annually. To provide this information for intermediate certificates, [https://www.ccadb.org/cas/intermediates directly update the corresponding record in the CCADB] then click on the "Audit Letter Validation [ALV]" button. Whenever the audit statements for an intermediate certificate are the same as the certificate that signed it, then check the “Audits Same as Parent” checkbox instead of providing separate audit information. When the "Audits Same as Parent" field is checked for an intermediate certificate record in the CCADB, the CCADB will look up the parent chain until audit statements are found, and then run ALV using those audit statements. When the "Audits Same as Parent" field is not checked, the CCADB will directly pass the audit statements in the intermediate certificate record into ALV.
| |
| | |
| The following two fields are set by running ALV on an intermediate certificate record in the CCADB. CAs may cause ALV to be run on the record by clicking on the "Audit Letter Validation [ALV]" button. Additionally CCADB has automated processes that will regularly check for intermediate certificate records that need to have ALV run.
| |
| # Standard Audit ALV Found Cert
| |
| #* This field will be set to PASS when ALV finds the SHA-256 Fingerprint for that certificate in the standard audit statement.
| |
| # BR Audit ALV Found Cert
| |
| #* This field will only be set when the "Derived Trust Bits" field has 'Server Authentication' in its list.
| |
| #* This field will be set to PASS when ALV finds the SHA-256 Fingerprint for that certificate in the BR audit statement. | |
| | |
| When ALV returns FAIL for either "Standard Audit ALV Found Cert" or "BR Audit ALV Found Cert" for one of your CA's intermediate certificate records in the CCADB, do the following.
| |
| * Check the corresponding audit statement to make sure the SHA-256 fingerprint of the certificate is correctly listed.
| |
| * If the SHA-256 fingerprint is listed in the audit statement, then make sure that it meets the [https://www.ccadb.org/policy#51-audit-statement-content format specifications], such as no colons, no spaces, no line feeds.
| |
| ** For existing audit statements (e.g. audit statements issued in 2019) add a comment to the "Standard Audit ALV Comments" or "BR Audit ALV Comments" fields indicating that the SHA-256 fingerprint of the certificate is listed but has a formatting problem that will be fixed in the next annual audit statement.
| |
| ** For new audit statements (e.g. audit statements issued in 2020 or later) have your auditor provide an updated audit statement that follows the [https://www.ccadb.org/policy#51-audit-statement-content formatting requirements] for the SHA-256 Fingerprints.
| |
| * If you do not agree with the ALV results, add comments to the "Standard Audit ALV Comments" or "BR Audit ALV Comments" fields to indicate that the SHA-256 fingerprint is listed correctly in the audit statement.
| |
| * If the audit statement is indeed missing the SHA-256 fingerprint for the certificate, then file an [[CA/Responding_To_An_Incident|Incident Report]], and add the link to the Incident Report in Bugzilla to the "Standard Audit ALV Comments" or "BR Audit ALV Comments" fields.
| |
| | |
| Derived Trust Bits logic:
| |
| * If the certificate has an Extended Key Usage (EKU) extension, then the "Derived Trust Bits" field is set to values in that extension.
| |
| * Otherwise CCADB checks the root certificate that the certificate chains up to.
| |
| ** If the root certificate is in only one of Mozilla'a or Microsoft's root stores then the "Derived Trust Bits" field is set to the trust bits that are enabled for that root certificate by that root store.
| |
| ** If the root certificate is in both Mozilla'a and Microsoft's root stores then the "Derived Trust Bits" field is set as the union of the trust bits that are enabled for the root certificate in both programs.
| |
| | |
| '''Important clarifications:'''
| |
| * Intermediate certificates that are not intended for TLS usage but are not [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#531-technically-constrained technically constrained via EKU] are considered technically capable certificates which must either be listed in the CA’s BR audit, be revoked or expired, or be added to OneCRL. Be aware that other root programs may not accept inclusion in OneCRL as sufficient remediation.
| |
| * Each copy or doppelganger (same Subject+SPKI) intermediate certificate must have their SHA-256 Fingerprint listed in appropriate audit statements according to the "Derived Trust Bits" field.
| |
| * [https://groups.google.com/d/msg/mozilla.dev.security.policy/89iF_4Ovpwg/YsC8CQ43DwAJ Cross-Certificates] are also considered intermediate certificates, which must also be audited and specifically listed in the applicable audit statements according to the "Derived Trust Bits" field.
| |
| * Self-signed certificates that are doppelganger (same subject + SPKI) certificates with a root certificate that is included in a root store are treated by browsers as intermediate certificates, so must also be listed in the applicable audit statements according to the "Derived Trust Bits" field.
| |
| | |
| '''Acceptable remediation''' for an intermediate certificate missing BR audits may include one or more of the following:
| |
| * Have your auditor issue a revised report that includes the intermediate certificate. Note that if the certificate has been in existence for multiple past audit periods, this will not be considered a full remediation unless new reports are supplied for all of those periods in which the certificate did not appear on the original reports.
| |
| * Revoke the intermediate certificate in accordance with BR section 4.9. If your CA decides not to revoke the certificate within the timeline specified by the BRs, then that is another incident, which must be addressed in a [[CA/Responding_To_An_Incident#Incident_Report|separate Incident Report]].
| |
| * If the intermediate certificate is technically capable but not intended for TLS issuance, and revocation is not imminent, you may request that Mozilla add it to OneCRL by adding a comment to the Bugzilla bug with the request and [[certificates@mozilla.org|sending email to Mozilla]]. Note: While adding the certificate to OneCRL satisfies Mozilla's expectations for remediation, it may not satisfy other root store programs. You are advised to seek their guidance on this issue.
| |
| | |
| = Common ALV Findings =
| |
| <To Do>
| |