|
|
| 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]
| |
| * [[CA/Audit_Letter_Validation#Common_ALV_Findings|Common ALV Findings]]
| |
| | |
| = 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.
| |
| | |
| 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.
| |
| | |
| 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.
| |
| | |
| '''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.
| |
| | |
| '''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.
| |
| * If multiple intermediate certificates with the same [https://tools.ietf.org/html/rfc5280#section-4.1.2.6 Subject] + [https://tools.ietf.org/html/rfc5280#section-4.1.2.7 SPKI] have been issued, each one 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 share a [https://tools.ietf.org/html/rfc5280#section-4.1.2.6 Subject] and [https://tools.ietf.org/html/rfc5280#section-4.1.2.7 SPKI] with a root certificate that is included in a root store are treated by browsers as intermediates because they chain up to an included root, so these certificates must also be listed in the applicable audit statements according to the "Derived Trust Bits" field. An example of this situation is when an older version of a root certificate exists but a newer version of the root certificate was created in order to be included in Mozilla's root store. In this case, a valid chain may be constructed as: leaf --> untrusted root --> trusted root. In other words, that "untrusted" root is technically trusted by Mozilla because it chains to a trusted root, so it's SHA256 fingerprint must also be listed in the applicable audit statements.
| |
| | |
| '''Acceptable remediation:''' <br />
| |
| Remediation may include one of the following when a [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#531-technically-constrained non-technically-constrained] intermediate certificate is missing from an audit statement. Note that [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#532-publicly-disclosed-and-audited Mozilla's Root Store Policy] says: "If the CA has a currently valid audit report at the time of creation of the certificate, then the new certificate MUST appear on the CA's next periodic audit reports."
| |
| * Have your auditor issue a revised report that includes the intermediate certificate.
| |
| ** This will '''not''' be an acceptable remediation if the certificate has been in existence for past audit periods.
| |
| ** This is an acceptable remediation when the certificate is self-signed and has the same Subject and SPKI as other certificates listed in the audit statement. For example, this can happen when Mozilla includes one version of a root certificate, but another version of the root certificate can be part of a valid chain constructed as: leaf --> untrusted root --> trusted root.
| |
| * Revoke the intermediate certificate in accordance with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#6-revocation Mozilla's Root Store Policy].
| |
| ** If your CA decides not to revoke the certificate within the timeline specified by section 4.9 of the [https://cabforum.org/baseline-requirements-documents/ 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 [mailto: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.
| |
| | |
| | |
| | |
| '''CA Task List''': A report is available via a Task List item on each CA's CCADB home page which identifies intermediate certificate records that have FAIL for either "Standard Audit ALV Found Cert" or "BR Audit ALV Found Cert". In the summary section of the CA Task List this item is called "Intermediate Certs with Failed ALV Results", and the corresponding report (available when the value is non-zero) is called "Check failed Audit Letter Validation (ALV) results".
| |
| | |
| = Common ALV Findings =
| |
| {| class="wikitable"
| |
| |-
| |
| ! Error !! Meaning !! Recommended Action
| |
| |-
| |
| | Thumbprint not found || SHA-256 Fingerprint of the certificate not found in the audit statement. || Check that the SHA-256 fingerprint for the certificate is clearly listed in in the audit statement and follows the [https://www.ccadb.org/policy#51-audit-statement-content format requirements]; e.g. the fingerprint contains no colons, no spaces, no line feeds. Request an updated audit statement from your auditor that clearly specifies the SHA-256 Fingerprints of each root and intermediate certificate that was in scope of the audit, using the correct formatting for the fingerprints.
| |
| |-
| |
| | Statement Date Not Found || The audit statement date was not found in the audit statement. || Check that the date that the audit statement was issued is clearly indicated in the audit statement and follows the [https://www.ccadb.org/policy#51-audit-statement-content format requirements] for dates. If needed, request an updated audit statement from your auditor. Sometimes ALV gives false alerts for dates, so if needed you may add a Case Comment about that.
| |
| |-
| |
| | Audit Period Not Found || ALV was unable to find the audit period start and end dates in the audit statement. || If the dates in the audit statement follow the [https://www.ccadb.org/policy#51-audit-statement-content format requirements], then this error can also be the result of the audit period being stated in various locations throughout the document or separately in different rows within a table, etc. It helps ALV for the audit period to be stated towards the top of the document and included with words like "during the period from May 1, 2018 through April 30, 2019".
| |
| |-
| |
| | Failed to validate EKU ... because the standard names and standard policies are not found in the audit letters || ALV was unable to find the specific text (case insensitive) that it looks for for each EKU. For example, "319 411-1 v1.1.1, dvcp;ovcp;ptc-br" || Make sure that the audit statement correctly indicates the audit criteria that was used, and that it satisfies [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#312-required-audits Mozilla's requirements].
| |
| Examples of the policy information that ALV looks for (depending on derived trust bits):
| |
| * ETSI EN 319 411-1 V1.2.2, LCP;DVCP
| |
| * ETSI EN 319 411-1 V1.2.2, LCP;OVCP;EVCP
| |
| * ETSI EN 319 411-1 V1.2.2, NCP;EVCP
| |
| * ETSI EN 319 411-1 V1.2.2, NCP;NCP+
| |
| * ETSI EN 319 411-2 V2.2.2, QCP-w
| |
| * ETSI EN 319 411-2 V2.2.2, QCP-w; EVCP
| |
| * ETSI EN 319 411-2 V2.2.2, QCP-l;QCP-l-qscd;QCP-n;QCP-n-qscd
| |
| * WebTrust Principles and Criteria for Certification Authorities v2.1
| |
| * WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security v2.2
| |
| * WebTrust Principles and Criteria for Certification Authorities - Extended Validation SSL v1.6.2
| |
| |-
| |
| | Auditor Not Found || ALV was unable to find the specified auditor name in the audit statement || Ensure the correct Auditor is selected in the record and that it matches the auditor name recorded in your audit statement. If both look correct ask a root store manager to update the auditor's information in the CCADB.
| |
| |-
| |
| | CA Owner Not Found || ALV was unable to find the CA Owner's name (as specified in the CCADB) in the audit statement. For intermediate certificate records with their own audit statements this will be the value in the "Subordinate CA Owner" field || Check that your CA Name in the CCADB is correct and that your CA Name specified in the Audit Letter is correct. For Audit Cases with this problem, you may ask a root store manager to update your CA Owner Name. For intermediate certificates with their own audit statements, you should update the "Subordinate CA Owner" field directly to match the CA name in the audit statement.
| |
| |-
| |
| | Download Audit Letter Fail || The provided link to the audit statement did not work. || Correct and test the audit statement links in the CCADB record then try again.
| |
| |-
| |
| | Audit Letter Not Found In Certain Location || CCADB contains a list of known audit locations, such as auditor websites and cpacanada.ca. This error will be given when the URL to the audit statement does not match any of the URLs in the known audit locations. || If you are testing the preliminary audit statement, then you may ignore this error. However, if you are running ALV on the final audit statement, then this error should not happen unless the audit statement is qualified (WebTrust) or the ETSI Certificate was not issued. [https://www.ccadb.org/policy#51-audit-statement-content In those situations] the root store operator will need to contact the auditor, so it will help if you provide the auditor's contact information in a Case Comment. If the audit statement is on the auditor's website and you are still receiving this error, then ask a root store manager to add the auditor's website to the list of known audit locations for ALV. Note: First check that you are using https instead of http for the audit URL.
| |
| |-
| |
| | Audit Letter Not PDF || ALV was unable to download and parse the document at the audit statement URL. || Update the Audit Statement links in the record to point to a valid PDF file.
| |
| |}
| |