CA/Audit Statements

From MozillaWiki
< CA
Revision as of 19:02, 24 June 2020 by Kathleen Wilson (talk | contribs) (formatting to clarify steps)
Jump to navigation Jump to search

CA Audits are one of the primary mechanisms relied upon by Mozilla to ensure that a CA is operating securely and in compliance with our policies. CA audits and audit statements must comply with the following requirements.

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.

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.

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's 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's 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. 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:
Remediation may include one of the following when a non-technically-constrained intermediate certificate is missing from an audit statement. Note that 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 Mozilla's Root Store Policy.
    • 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.
  • 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.

Audit Delay

If a CA fails to deliver audit statements to Mozilla when they are due, Mozilla may take action to reduce the risks this presents to our users. The following guidance is intended for CAs in such a situation.

When a CA realizes that their audits will be delayed by a force majeure, Mozilla expects the CA to promptly disclose the issue, to provide regular updates, and to remain fully compliant with all other aspects of the Mozilla Root Store policy. CAs that are unable to deliver timely and complete audit statements should arrange with their auditors to supply Mozilla with partial information whenever possible, via publicly-available audit statements listing qualifications, agreed-upon procedures (AUP) reports, or similar partial reporting mechanisms (described in more detail below).

The CA must file an incident bug in Bugzilla to provide an Incident Report explaining the situation with their audits, mitigations that have been or will be implemented, and their plan to move forward in reaching compliance again.

  • Whiteboard = [ca-compliance][audit-delay]
  • For audit delays due to mandated restrictions regarding COVID-19, use Whiteboard = [ca-compliance][audit-delay][covid-19]

Minimum Expectations

Situations will be considered and treated on a case by case basis.
Both ETSI and WebTrust Audits should:

  • Disclose each location (at the state/province level) that was included in the scope of the audit or should have been included in the scope of the audit, whether the inspection was physically carried out in person at each location, and which audit criteria were checked (or not checked) at each location.
    • If the CA has more than one location in the same state/province, then use terminology to clarify the number of facilities in that state/province and whether or not all of them were audited. For example: "Facility 1 in Province", "Facility 2 in Province, Facility 3 in Province" or "Primary Facility in Province", "Secondary Facility in Province", "Tertiary Facility in Province".
      • The public audit statement does not need to identify the type of Facility.
      • "Facility" includes: data center locations, registration authority locations, where IT and business process controls of CA operations are performed, facility hosting an active HSM with CA private keys, facility or bank deposit box storing a deactivated and encrypted copy of a private key.

ETSI Audits

Guidance provided in mozilla.dev.security.policy included the following:
If facilities can’t be audited by auditors of the CAB in person, possible alternatives are:

  • “Network-assisted auditing techniques” are possible (ETSI EN 319 403, 7.4.1.2) or
  • CAB may subcontract auditors that do not fall under the restriction, if they fulfil the auditor requirements. The CAB always remains fully responsible for such outsourced activities. (ISO/IEC 17065, 6.2.2 ).

If such alternatives were accepted by the CAB to provide reasonable assurance with regard to the requirements to be audited, this would result in a normal audit conclusion and would not be visible on an audit attestation letter.

An ETSI audit shall be performed in any case making sure that everything which reasonably can be audited will be audited - there is especially no restriction to do a full Stage 1 document audit. If facilities cannot be audited by auditors of the CAB in person and the two alternatives stated above are not possible or the CAB does not regard them to provide reasonable assurance with regard to the requirements to be audited in order to draw a reasonable audit conclusion this shall be documented in the audit report.
In any case an ETSI Audit Attestation Letter (AAL) shall be issued for the required audit period clearly stating in case limitations have been encountered by the auditor: the type of the limitation (e.g. control not audited in person or not audited at all) and description of the limitation (e.g. which controls were not covered in person or not covered at all).

After audit restrictions have been lifted: An ETSI audit shall be performed as soon as restrictions have been lifted. It is possible to re-use the original audit results and perform an additional audit just with regard to the non audited requirements (ISO/IEC 17065, 7.4). Usually, the period during which this is possible is limited by the CAB (ACAB’c: 6 month). Once the original audit becomes too old, a completely new audit would be necessary. Therefore, the ETSI audit shall

  • either be focused on the parts not covered throughout the previous audit as stated in the AAL and comprise the same audit period as stated in the last report. In this case an amendment AAL for the original period would to be issued even it is dated more than 3 month after the end of the audit period.
  • or comprise the full audit scope of an ETSI audit and the audit period starting with the same begin date as stated in the last report. In this case a new AAL will be issued replacing the previous one and resulting in an extend period of more than 12 month.

Please note: Such an extend period would only be possible, if a new full audit has been performed (covering the time of the original period plus the extension till the last day of the audit).

For more guidance please refer to www.acab-c.com or send your request to cabforum@acab-c.com.

WebTrust Audits

Guidance provided in mozilla.dev.security.policy included the following:
Ultimately, when an auditor is not able to obtain assurance on the entire scope of the engagement, and realizing a carved out approach is not permitted in a WebTrust audit, for example, when a certain data center is not able to be visited to observe controls operating and underlying documentation, the auditor will not be able to provide an unmodified/unqualified/clean opinion and the client would not be able to display the WebTrust seal. In these situations, the auditor would include an explanatory paragraph that details what gave rise to the scope limitation and issue one of the following modified opinions:

  • Qualified opinion (when conditions are least severe but significant enough to mention), stating an except for paragraph explaining the condition(s) arising from the scope limitation, such as not being able to test the data center.
  • Adverse opinion (when conditions are more severe), stating that the conditions are such that due to the severity of the scope limitation, the auditor states controls are not operating effectively and they were not able to satisfy themselves that the necessary controls were able to operate.
  • Disclaimer of opinion (when conditions are most severe), stating that the auditor is unable to form any opinion due to the nature of the scope limitation.

If the potential threat of a scope limitation is primarily due do an auditor not being able to travel to perform necessary testing, as with the Coronavirus, there are potential remedies for the auditor to consider, including, but not limited to:

  • Using the work of another auditor, whereby the lead auditor verifies the independence, qualifications and technical competency of another firm that can do a portion of the work, and the lead auditor directs the work, plans, supervises and reviews the other auditor’s work, taking ultimate responsibility. In this case, no mention of the other firm is made in the report as the lead auditor is taking responsibility for the other firm’s work.
  • Using technology to observe physical controls and underlying documents/artifacts via remote means, such as video. In this case, the auditor must ensure the authenticity, integrity, security and confidentiality of the transmission.

Auditor Qualifications

Section 3.2 of Mozilla's Root Store Policy says: "Mozilla requires that audits MUST be performed by a Qualified Auditor, as defined in the Baseline Requirements section 8.2."

Section 8.2 of the Baseline Requirements says: The CA’s audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills:

  1. Independence from the subject of the audit;
  2. The ability to conduct an audit that addresses the criteria specified in an Eligible Audit Scheme (see Section 8.1);
  3. Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function;
  4. (For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with ISO 17065 applying the requirements specified in ETSI EN 319 403;
  5. (For audits conducted in accordance with the WebTrust standard) licensed by WebTrust;
  6. Bound by law, government regulation, or professional code of ethics; and
  7. Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage.

Verifying WebTrust Auditor Qualifications

For WebTrust auditors, a representative of Mozilla confirms that the auditor's name and country are listed in CPA Canada's Licensed WebTrust practitioners web page. Send email to webtrust@cpacanada.ca for more information about this list or about the process to become a licensed WebTrust practitioner.

Verifying ETSI Auditor Qualifications

For ETSI auditors, a representative of Mozilla checks to verify the qualifications of both the National Accreditation Body (NAB) and the Conformity Assessment Body (CAB) which is the auditor.

Simplified Check

Check whether the accredited CAB is listed as ACAB’c member in https://www.acab-c.com/acab-c-members

  • All ACAB’c member CABs were carefully vetted that they:
    1. possess the required accreditation as per the Standard Check;
    2. have signed the ACAB’c code of conduct; and
    3. use the Audit Attestation template agreed with the Browsers via the CA/Browser Forum.

Standard Check

  • Require the ETSI auditor to provide as evidence links to their National Accreditation Body (NAB) and their accreditation documentation, listed by the NAB on their webpages.
  • Confirm the following:
    • The NAB is listed as “full member” under https://european-accreditation.org/ea-members/directory-of-ea-members-and-mla-signatories/
    • The accreditation documentation was issued by that NAB and is hosted on the NAB's website
    • The CABs accreditation documentation explicitly refers to all of the following:
      • ETSI EN 319 403
        • as the relevant standard for the CAB to perform ETSI audits, allocated under ISO 17065 as framing standard.
        • The EU eIDAS Regulation 910/2014 can be listed to supplement that information but – alone – is not sufficient to demonstrate ETSI auditors qualification.
      • ETSI EN 319 401 and ETSI EN 319 411-1
        • as standards to audit publicly trusted CA/Trust Service Provider
      • ETSI EN 319 411-2
        • as standard to audit publicly trusted CA/Trust Service Provider
        • which issue QWACS certificates according to the EU eIDAS Regulation 910/2014.

Comprehensive Check

This check is only needed if the Standard Check was not successful.

  • Require the ETSI auditor to provide a comprehensive written explanation about why they are not conformant with the above mentioned scheme. The auditor must provide a rationale clearly referring back to all of the following:
    • European Accreditation to demonstrate they act under the EU accreditation scheme,
    • ISO 17065 plus ETSI EN 310 403 to demonstrate they are accredited/allowed to audit publicly trusted CA/Trust Service Provider according to ETSI EN 319 401 and ETSI EN 319 411-1 and
    • ETSI EN 319 411-2 for QWACS certificates according to the EU eIDAS Regulation 910/2014.
  • Review the documents and explanation.
  • Request external review from ACAB’c to provide opinion about the CAB's accreditation.
Retrieved from "https://dev.wikimo.nonprod.webservices.mozgcp.net/index.php?title=CA/Audit_Statements&oldid=1228431"