CA/BR Audit Guidance

Baseline Requirements (BRs)

The CA/Browser Forum's Baseline Requirements provide a foundation for best practices across the industry by defining a single, consolidated set of essential standards for all SSL/TLS certificates. The initial Effective Date of the BRs was 1 July 2012. Refer to the Document History section of the BRs for further information about BR Effective Dates and Relevant Compliance Dates.

Version 2.1 of Mozilla's CA Certificate Inclusion Policy added the requirement that SSL certificate issuance also be audited annually according to the BRs. This means that CAs with a root certificate included in Mozilla's Program that has the websites (SSL/TLS) trust bit enabled must have their SSL certificate issuance and operations audited annually according to the BRs. Additionally, any Certificate Authority being considered for root inclusion must have a Baseline Requirements audit performed if the websites trust bit is to be enabled for the new root certificate.

This page provides further information about Mozilla's expectations regarding CA compliance with the BRs, and auditing according to the BRs.

BR Audits

As with the other audits required of CAs in Mozilla's Program, the BR Audit statement must be a public-facing document. Section 6 of Mozilla's CA Certificate Inclusion Policy says: "We require that all CAs whose certificates are distributed with our software products: ... publicly disclose information about their policies and business practices (e.g., in a Certificate Policy and Certification Practice Statement); ... provide *public attestation* of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the CA’s internal operations."

As previously stated, it is acceptable for an audit statement to list the BRs that the CA is not yet fully in compliance with. However, this may result in an auditor providing information in the BR audit statement that the CA considers sensitive (e.g. subordinate CA specifics, RA information, customer information, or security sensitive information). Each CA must work with their auditor to create a public-facing BR audit statement that does not have information in it that the CA considers sensitive, but that sufficiently lists the BRs that the CA is still working to conform with.

Here are some examples of the level of information that should be included in the BR audit statement in regards to BRs that the CA is not yet fully conforming to.

• BR 9.5 – 1024-bit certs with validity beyond 2013 (in order to support legacy customer apps)
• BR 13.2.6 - OCSP giving status “good” for unknown serial numbers.
• BR 16.5 - multi-factor authentication for all accounts capable of directly causing certificate issuance
• BR 17.5 - The audit period for the Delegated Third Party SHALL NOT exceed one year
• BR 17.8 – audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken
• BR 11.2 – re-verifying identity for cert renewal requests

RFC 5280

A BR audit must include checks to verify that the root, intermediate, and SSL certificates conform to RFC 5280. Given that the BRs normatively incorporate RFC 5280, auditors MUST be checking compliance in order to evaluate whether or not a given certificate conforms to the BRs.

BR section 4: "Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280."

BR Appendix B:

• "All other fields and extensions MUST be set in accordance with RFC 5280."
  • Note: "fields" includes non-extension fields.
• "Non-critical Name Constraints are an exception to RFC 5280 (4.2.1.10), however, they MAY be used..."

RFC 5280 is clear as a profile of what constitutes a 'valid' PKIX X.509 certificate. Fields that fail to adhere to the technical requirements do not conform to the BRs. For example, RFC 5280 Section 4.1.2.2: "The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer."

Whole-Population Audit of Intermediate Certs

BR Audits must always include the whole-population audit of intermediate certificates that are capable of issuing SSL certs. The CA's roots and all of their intermediate certificates (that are capable of issuing SSL certs) must always be audited for conformance to the stated standards. In the BR audit, sampling can be used only for end-entity certificates.

Auditing of root and intermediate certificates must include checking compliance with the BRs and with RFC 5280. For example:

• Intermediate certificates must be checked for duplicate serial numbers, which is forbidden by section 4.1.2.2 of RFC 5280.
• Cryptographic algorithm and key sizes must meet BR Appendix A.
• Certificate Extension must comply with BR Appendix B.
• Intermediate certificates must either be technically constrained or publicly disclosed and audited as described in Mozilla's CA Certificate Inclusion Policy and BR sections 9.7 and 17.

Definition: An intermediate certificate that does not have an Extended Key Usage (EKU) extension, has id-kp-serverAuth extended key usage, or has the anyExtendedKeyUsage KeyPurposeId is considered capable of issuing SSL certificates.

All root and intermediate certificates must be audited according to the Baseline Requirements, and end entity certificates may be audited on a sample basis. For the above diagram:

• Public Root CA must be audited
• Sub CA 1 which issues SSL certificates would be subject to audit, PLUS its end-entity certificates would need to be audited at least on a sample basis
• Sub CA 2, with an EKU that allows SSL certificates, would be subject to audit, PLUS its end-entity certificates as well to verify that no SSL certificates have been issued.
• Sub CA 3, operated by ABC Corp, is subject to audit
• Sub CA 3a PLUS its end-entity certs are subject to audit
• Sub CA 3b is subject to audit, but not its end-entity certificates because the EKU restricts to SMIME only
• Sub CA 4, operated by XYZ Corp, is subject to audit, but not its end-entity certificates because Sub CA 4 is technically constrained in line with BRs

The colors in the above diagram represent the following:

• Green -- All green certificates are in full scope, must be audited. End-entity certs may be sampled.
• Yellow -- The subordinate CA certificate is in scope of audit, but the certificates below it are not in scope.
• Red -- The certificates that are not in scope of audit.
• Blue -- The blue certificates should not be in scope, but since the subordinate CA certificate did not have the EKU to prevent SSL certificate issuance, the auditor must perform procedures to confirm that there are no SSL certificates.

WebTrust BR Audit Statement

Mozilla accepts the following BR Criteria provided by WebTrust:

• Principles and Criteria - SSL Baseline Requirements Version 1.1. (Amended) (Superseded)
• WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security – Version 2

The audit statement must specify the audit period dates, and that the audit was based on the "AICPA/CICA WebTrust for Certification Authorities – SSL Baseline Requirements Audit Criteria" or the "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security". It is recommended that the audit statement include the version of the criteria that was used.

The BR audit statement may be included in the same pdf file as the WebTrust for Certification Authorities audit statement.

The BR audit statement may be qualified and list BRs that the CA is not yet in compliance with. The second BR audit (the following year) is expected to confirm that the issues that were listed in the previous BR audit have been resolved.

Definition: A qualified audit statement is issued when the auditor encountered one or more instances in which the CA does not comply with the audit criteria, however the CA is in compliance with the rest of the audit criteria.

Extended Validation

• PROPOSED Text -- under discussion in mozilla.dev.security.policy

If the root certificate is enabled for EV treatment, then the following three public-facing audit statements are required annually:

1. WebTrust CA -- WebTrust Principles and Criteria for Certification Authorities
2. WebTrust BR -- WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security (or Principles and Criteria - SSL Baseline Requirements)
3. WebTrust EV -- WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL (or Principles and Criteria for Certification Authorities – Extended Validation Audit Criteria)

However, if the CA hierarchy can only be used for EV certificates, and the CP/CPS clearly states this, then a separate WebTrust BR audit statement is not needed because it is encompassed within the WebTrust EV audit. In other words, the WebTrust EV audit statement will also suffice as the WebTrust BR audit statement.

ETSI BR Audit Statement/Certificate

According to section 11 of Mozilla's CA Certificate Inclusion Policy, when the websites trust bit is enabled, the only ETSI criteria that is acceptable to Mozilla is ETSI TS 102 042 V2.3.1 or later (as applicable to the "EVCP" and "EVCP+" certificate policies, DVCP and OVCP certificate policies for publicly trusted certificates - baseline requirements, and any of the "NCP", "NCP+", or "LCP" certificate policies). ETSI TS 101 456 audit criteria is not sufficient for CA whose root certificate has the websites (SSL/TLS) trust bit enabled; ETSI TS 101 456 may only be used for email certificates.

• Note: ETSI TS 101 456 has not been modified/updated to meet the Baseline requirements, but in ETSI they are developing a new set of standards that will replace the TS 102 042 and 101 456, and for all of these the Baseline requirements will be taken into account in case the scope of the BRs ever go beyond the SSL certs and affect all type of certs used in a web browser.

For an ETSI TS 102 042 certificate to be accepted as a BR audit statement, the certificate must include PTC-BR and must be of version 2.3.1 or later. Note: PTC-BR stands for "Publicly Trusted Certificates - Baseline Requirements"

Mozilla also requires evidence of annual surveillance audits, as required in order to keep the ETSI certificate valid. The statement of annual surveillance audit must include the dates over which the audit was performed, and the version of the audit criteria that was used.

ETSI Information/Resources:

• http://www.etsi.org/index.php/technologies-clusters/technologies/security/certification-authorities-and-other-trust-service-providers
• http://portal.etsi.org/TBSiteMap/ESI/TrustServiceProviders.aspx

A CA's First BR Audit

We previously said: "Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA Certificate Policy. This includes having a Baseline Requirements audit performed if the websites trust bit is to be enabled. *Note that the CA's first Baseline Requirements audit may be a Point in Time audit.*"

To clarify, if the root certificate is not yet in production and is not yet issuing certificates to customers, then a Point in Time Readiness Assessment of BR compliance (BR PITRA) may be used. In this case a BR PITRA prior to inclusion may be used, but the next annual audit after inclusion would need to be a full performance audit. Note: If the inclusion process spans more than one annual audit cycle, then more than one BR PITRA may be used, until the root certificate has been included or the root certificate is put into operation producing certificates for customers, whichever comes first.

In general, there are 4 scenarios when a point-in-time BR audit may be used:

1. An organization is standing up a CA for the first time, wants to issue public SSL certs, so the first audit would be point in time, with all subsequent audits being period of time.
2. A private CA who has been issuing SSL certificates (for example, an internal Enterprise CA) wants to be included in a root programme (or be cross-certified to an existing public CA) would have a point in time BR audit as part of their preparation activities for ‘going public’ and subsequent audits as period of time.
3. A public CA who has never issued SSL certificates (and their Root CA certificate is not trusted for SSL) wants to build an SSL hierarchy and begin issuing SSL certs – the first audit can be point in time and all subsequent audits period of time
4. Any CA who has received a qualified BR audit opinion (i.e. failing criteria) for its regular period of time audit and then conducts remediation may want a point in time audit to demonstrate their remediation efforts

When the root certificate is in production and has issued certificates to customers the first BR audit must be a full performance audit showing BR compliance over at least 60 days. This situation occurs when a CA applying for inclusion did not know about the BRs, so did not get audited according to the BRs during their previous audit cycle. However, the CA does have a current valid audit statement indicating compliance with WebTrust Principles and Criteria for Certification Authorities or ETSI TS 102 042. This shorter period-of-time audit is intended for CAs to use for their first BR audit, so they will not have to go through another full-year audit until their next regularly scheduled annual audit.

In the situation where a root certificate is in production and has issued certificates to customers before the CA knew about the BRs, an untold number of the previously issued certificates might not conform to the BRs. This could be serious, depending on which BRs the CA did not previously comply with, the number of BRs the CA did not previously comply with, and the quantity of such certificates issued. Depending on the situation, the CA may be asked to create a new root certificate for inclusion. Therefore, the CA and/or auditor shall provide a list of the BRs that the previously issued certificates did not comply with.

Auditor Qualifications

Auditor Qualifications are described in

• Section 17.6 of the CA/Browser Forum's Baseline Requirements
• Items 13 and 14 of Mozilla's CA Certificate Inclusion Policy

Audit Mistakes

During evaluation of a CA's root inclusion or change request, Mozilla uses public audit statements to help confirm that the CA is in compliance with the stated verification requirements, the BRs, and Mozilla's policy. Therefore, when members of Mozilla's community find a problem with certificates in the CA's hierarchy that should have been noted in the audit statement (as an exception or point of non-compliance), the CA may need to be re-audited to confirm that the problem has been resolved.

When egregious mistakes were overlooked by the auditor, or there are a significant number of oversights, or the auditor did not notice BR compliance problems with the root or intermediate certificates, then the CA must resolve the issues and be re-audited. For the re-audit the CA can either get re-audited by a different auditor, or have the current auditor provide an immediate plan for correction and compliance, and then present a mid-term partial audit following that plan. In either case, the auditor must provide documentation about steps they are taking to avoid making the same mistakes in future audits. If the auditor fails to assure Mozilla that they have corrected the deficiencies in their auditing process, then their standing as a trusted auditor for the Mozilla root program may be jeopardized.

Non-compliance to the following policies are examples of mistakes that auditors must not overlook.

• BR Appendix A for root and intermediate certs - Cryptographic Algorithm and Key Requirements (Normative) - Certificates MUST meet the following requirements for algorithm type and key size.
• BR Appendix B for root and intermediate certs – Certificate Extensions (Normative) - This appendix specifies the requirements for Certificate extensions for Certificates generated after the Effective Date.
• With regards to root and intermediate certificates, the items listed in section 4 of Mozilla CA Certificate Inclusion Policy:
  • ASN.1 DER encoding errors;
  • invalid public keys (e.g., RSA certificates with public exponent equal to 1);
  • duplicate issuer names and serial numbers;
  • incorrect extensions (e.g., SSL certificates that exclude SSL usage, or authority key IDs that include both the key ID and the issuer’s issuer name and serial number); or
  • cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists.

There are other types of mistakes that could potentially not be found by an auditor doing sampling of end-entity certificates. If the auditor did not note this type of mistake in the audit statement, then the CA must fix the mistake(s) and be re-audited to confirm that the problem has been resolved. The CA may use the same auditor that issued the previous audit statement.

Non-compliance to the following policies are examples of mistakes that auditors might overlook due to sampling of end-entity certificates:

• BR 9.2.1 - Subject Alternative Name Extension - SSL certs must contain at least one entry
• BR 9.2.2 - Subject Common Name Field - If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension
• BR 9.4.1 - Subscriber Certificates - Subscriber Certificates issued after the Effective Date (1 July 2012) MUST have a Validity Period no greater than 60 months. (exceptions allowed)
• BR Appendix A for Subscriber certs - Cryptographic Algorithm and Key Requirements (Normative) - Certificates MUST meet the following requirements for algorithm type and key size.
• BR Appendix B for Subscriber certs – Certificate Extensions (Normative) - This appendix specifies the requirements for Certificate extensions for Certificates generated after the Effective Date.
• The items listed in section 4 of Mozilla CA Certificate Inclusion Policy in end-entity certificates:
  • ASN.1 DER encoding errors;
  • invalid public keys (e.g., RSA certificates with public exponent equal to 1);
  • duplicate issuer names and serial numbers;
  • incorrect extensions (e.g., SSL certificates that exclude SSL usage, or authority key IDs that include both the key ID and the issuer’s issuer name and serial number); or
  • cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists.

Finally, there are a type of mistakes that may be found during the evaluation of a root inclusion/change request, and resolved by the CA without requiring a re-audit. If someone reports this type of mistake, then the CA must fix the mistake and provide examples to demonstrate that the problem has been resolved. Examples of this type of mistake include non-compliance with the following.

• BR 13.2.2 - Repository -- CRL and OCSP max expiration time, GET
• BR 3.2.5 OCSP Signing -- OCSP responses MUST conform to RFC2560 and/or RFC5019.
• Mozilla CA Certificate Maintenance Policy section 9: all new end-entity certificates must contain at least 20 bits of unpredictable random data (preferably in the serial number).

CA Conformance to the BRs

The CA's CP or CPS documents must include a commitment to comply with the BRs, as described in BR section 8.3.

BR section 8.2.1 says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements."

It is not sufficient to simply reference section 11 of the CA/Brower Forum's Baseline Requirements (BR). BR #11.1.1 lists several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing section 11 of the BRs does not specify which of those options the CA uses, and is insufficient for describing how the CA conforms to the BRs. The CA's CP/CPS must include a reasonable description of the ways the CA can verify that the certificate subscriber owns/controls the domain name(s) to be included in the certificate.

Checking BR Compliance

Problems to look for when analyzing data of existing sites chaining up to roots being considered for inclusion.

• BR Appendix A for Root, Sub CA, and Subscriber certs - Cryptographic Algorithm and Key Requirements (Normative) - Certificates MUST meet the following requirements for algorithm type and key size...
• BR Appendix B for Root, Sub CA certs, and Subscriber certs – Certificate Extensions (Normative) - This appendix specifies the requirements for Certificate extensions for Certificates generated after the Effective Date.
• Mozilla CA Certificate Inclusion Policy section 4: We reserve the right to not include a particular CA certificate in our software products. ... CAs that issue certificates that have:
  • ASN.1 DER encoding errors;
  • invalid public keys (e.g., RSA certificates with public exponent equal to 1);
  • duplicate issuer names and serial numbers;
  • incorrect extensions (e.g., SSL certificates that exclude SSL usage, or authority key IDs that include both the key ID and the issuer’s issuer name and serial number); or
  • cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists.
• BR 9.2.1 - Subject Alternative Name Extension - SSL certs must contain at least one entry
• BR 9.2.2 - Subject Common Name Field - If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension
• BR 9.4.1 - Subscriber Certificates - Subscriber Certificates issued after the Effective Date (1 July 2012) MUST have a Validity Period no greater than 60 months. (exceptions allowed)
• BR Appendix A for Subscriber certs - Cryptographic Algorithm and Key Requirements (Normative) - Certificates MUST meet the following requirements for algorithm type and key size.
• BR 9.6 - CAs SHOULD generate non-sequential Certificate serial numbers that exhibit at least 20 bits of entropy.
• BR 13.2.2 - Repository -- CRL and OCSP max expiration time, GET
• BR 3.2.5 OCSP Signing -- OCSP responses MUST conform to RFC2560 and/or RFC5019.
• Mozilla CA Certificate Maintenance Policy section 9: all new end-entity certificates must contain at least 20 bits of unpredictable random data (preferably in the serial number).
• The problems listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes
• The concerns listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix

Monitoring BR Compliance

• TO DO

Process for what happens when it is found that a CA is not complying with the BRs.

bug 1029147 - (BR-Compliance) Bug for Tracking BR Compliance Issues

http://www.roeckx.be/certificates/ -- overview of how well CAs are complying with the various standards like the CA/Browser forum baseline requirements and RFC 5280.

For different types of issues, may need different dates and seriousness ratings for the issue.

BR 13.1.5 - Reasons for Revoking a Subscriber Certificate - The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: ... 9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;

BR 13.1.6 - Reasons for Revoking a Subordinate CA Certificate - The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs: ... 5. The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with these Baseline Requirements or the applicable Certificate Policy or Certification Practice Statement;