Audit Letter Validation (ALV)

The CCADB uses an Audit Letter Validation (ALV) tool that is provided by Microsoft to automatically parse and validate audit statements. The ALV eliminates manual processing, but it requires audit statements to follow some basic rules in order to function properly. If an audit statement fails to meet any of the Audit Statement Requirements and Format Rules, the CA Owner will be asked to work with their auditor to provide an audit statement that passes ALV.

Table of Contents:

1. Root Certificates
2. Intermediate Certificates
3. Testing Audit Statements with ALV
4. Common ALV Findings

Root Certificates

CA Owners 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 Add/Update Root Request Case in the CCADB for a particular set of audits (e.g. Standard Audit, NetSec Audit, TLS BR Audit, TLS EVG Audit, Code Signing Audit, S/MIME BR Audit).

• Update audit, CP, CPS, and test website information in the CCADB

Intermediate Certificates

Subordinate CA Owners 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 a Root Store. Meaning that such subordinate CA Owners can also issue TLS certificates for any website or domain, so it is imperative that the same rules are being followed by all subordinate CA Owners operating non-technically-constrained intermediate certificates. There are currently about 150 root certificates in the Root Stores of CCADB Root Store Operators, which leads to about 3,000 intermediate certificates that are trusted.

Note: The CCADB considers the terms “intermediate” and “subordinate” synonymous.

To help enforce the rules at the intermediate certificate level, some CCADB Root Store Operators require disclosure of intermediate certificates. CCADB automatically runs ALV on the intermediate certificate records and reports the results to CA Owners and Root Store Operators in their CCADB home pages.

CA Owners are required to annually update the audit and CP/CPS for their non-technically-constrained intermediate certificates chaining to root certificates included in a Root Store. To provide this information for intermediate certificates, directly update the corresponding record in the CCADB then click on the “Audit Letter Validation [ALV]” button.

When the audit statements for an intermediate certificate are the same as the certificate that signed it, 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, 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 fields are set by running ALV on an intermediate certificate record in the CCADB. CA Owners may cause ALV to be run on the record by clicking on the “Audit Letter Validation [ALV]” button. Additionally, the 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.
• NetSec Audit ALV Found Cert
  • This field will be set to PASS when ALV finds the SHA-256 Fingerprint for that certificate in the NetSec Audit statement.
• TLS 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 TLS BR Audit statement.
• TLS EVG Audit ALV Found Cert
  • This field will only be set when the Derived Trust Bits field has “Server Authentication” in its list, and the EV SSL Capable field is set to TRUE.
  • This field will be set to PASS when ALV finds the SHA-256 Fingerprint for that certificate in the TLS EVG Audit statement.
• Code Signing Audit ALV Found Cert
  • This field will only be set when the Derived Trust Bits field has “Code Signing” in its list.
  • This field will be set to PASS when ALV finds the SHA-256 Fingerprint for that certificate in the Code Signing Audit statement.
• S/MIME BR Audit ALV Found Cert
  • This field will only be set when the Derived Trust Bits field has “Secure Email” in its list.
  • This field will be set to PASS when ALV finds the SHA-256 Fingerprint for that certificate in the S/MIME BR Audit statement.

When ALV returns FAIL for “Standard Audit ALV Found Cert”, “NetSec Audit ALV Found Cert”, “TLS BR Audit ALV Found Cert”, “EVG BR Audit ALV Found Cert”, “Code Signing Audit ALV Found Cert”, or “S/MIME 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.
• 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”, “NetSec Audit ALV Comments”, “TLS BR Audit ALV Comments”, “EVG BR Audit ALV Comments”, “Code Signing Audit ALV Comments”, or “S/MIME 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 to one of the “…ALV Comments” fields.

Important clarifications:

• If the CA Owner has a currently valid audit report at the time of creation of the intermediate certificate, then the current audit statement does not need to be updated and the new certificate must appear on the CA Owner’s next periodic audit reports.
• Intermediate certificates that contain “Server Authentication” in the Derived Trust Bits field are considered to be technically capable of issuing TLS certificates, and they must be listed in the corresponding CA Owner’s Audit report.
• 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 + SPKI with a root certificate that is included in a Root Store are treated by Root Store Operators as intermediate certificates 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 and a newer version of the root certificate is created. 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 the Root Store Operator because it chains to a trusted root, so it’s SHA256 fingerprint must also be listed in the applicable audit statements.

Acceptable remediation:

• Have your auditor issue a revised report that includes the intermediate certificate.
  • If the certificate has been in existence for past audit periods, then you must also file an Incident Report.
  • An Incident Report may not be needed if the certificate is self-signed and has the same Subject + SPKI as other certificates listed in the audit statement. For example, this can happen when a Root Store 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 Root Store policies and the BRs.
  • If your CA decides not to revoke the certificate within the timeline specified by Section 4.9 of the BRs, then that is another incident, which must be addressed in a separate Incident Report.

Testing Audit Statements with ALV

CA Owners may want to test preliminary audit statements to ensure the file will pass ALV before collecting a final copy from their auditor. CA Owners are encouraged to work with their auditor to coordinate preliminary audit statement testing. To test preliminary audit statements a CA Owner should:

1. Create the Add/Update Root Request Case in the CCADB.
2. In the ‘AUDITS’ tab of the Case, add Audit Firm information.
3. Add Audit Information to the Case, including a URL to where the preliminary audit statement is located.
   • These preliminary statements are typically uploaded to Bugzilla.
4. Add a Case Comment to the ‘CASE PROGRESS’ tab of the Case that says: “Preliminary Audit Reports” to inform Root Store Operators of your intent to test the preliminary audit statements.
5. Run ALV.
   • Ignore any ALV error related to the audit report not originating from a trusted location.
   • Work with the auditor to resolve other common ALV findings and errors.
   • If you encounter a problem not described on the common ALV findings page, contact support[at]ccadb[dot]org.
6. Once the errors are resolved, link to the final audit statements in the Audit Information Section of the tab in the existing “Add/Update Root Request” Case.

More detailed steps for testing preliminary audit statements can be found here.

Note: These instructions are specific to updating audit information for root CA certificates through a CCADB case. Guidance for managing Intermediate CA certificates (to include audit statements) can be found here.

Common ALV Findings

ALV formatting requirements are specified in section 5.1 of the CCADB Policy.