CA/Audit Letter Validation

The 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.

• 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 audit, CP, CPS and test website information for their certificate hierarchies at least annually. To provide this information for root certificates, 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.

• Audit Case Work Flow
• Detailed Instructions
  • Information Required to create an Audit Case
• Run ALV on Preliminary Audit Statements
• Common ALV Findings

Intermediate Certificates

Subordinate CAs who operate non-technically-constrained intermediate certificates have the keys to the internet just as much as the 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-technically-constrained intermediate certificates. There are currently about 150 root certificates in Mozilla's root store , which leads to about 2,500 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-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 audit and CP/CPS for their non-technically-constrained intermediate certificates chaining to root certs included in Mozilla's program at least annually. To provide this information for intermediate certificates, 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.

1. 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.
2. 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 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 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 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 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 Subject + SPKI have been issued, each one must have their SHA-256 Fingerprint listed in appropriate audit statements according to the "Derived Trust Bits" field.
• 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 Subject and 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.

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 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 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

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 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 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 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 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. 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.