November 2017 CA Communication


Dear Certification Authority,

This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program.

To respond to this survey, login to the Common CA Database (CCADB), click on the 'CA Communications (Page)' tab, and select the 'November 2017 CA Communication' survey. Please enter your response by December 15, 2017.

A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Kathleen Wilson
Mozilla CA Program Manager

ACTION 1: Review version 2.5 of Mozilla's Root Store Policy.

Changes that most likely require CA action:

  • Additional requirements were added for intermediate certificates that are used to sign certificates for S/MIME. In particular, such intermediate certificates must be name constrained in order to be considered technically-constrained and exempt from being audited and disclosed in the Common CA Database. By April 15, 2018, all intermediate certificates (that chain up to root certificates included in Mozilla's program) that are capable of issuing S/MIME certificates but are not name constrained must be either audited and disclosed in the Common CA Database, or be revoked. As of November 15, 2017, CAs must name-constrain all new intermediate certificates that are capable of issuing S/MIME certificates, or those intermediate certificates must be audited and disclosed in the Common CA Database. See Section 3.1.2 of Mozilla's Root Store Policy for details about required audits.

  • Clarified the information that must be provided in each audit statement , including the distinguished name and SHA-256 fingerprint for each root and intermediate certificate in scope of the audit.

  • Our policy on root certificates being transferred from one organization or location to another has been updated and included in the main policy. Trust is not transferable; Mozilla will not automatically trust the purchaser of a root certificate to the level it trusted the previous owner.

Changes that are clarification of previously expected practice or policy:

  • CAs are required to follow industry best practice for securing their networks, for example by conforming to the CA/Browser Forum’s Network Security Guidelines or a successor document.

  • CAs are required to use only those methods of domain ownership validation which are specifically documented in the CA/Browser Forum’s Baseline Requirements version 1.4.1.

  • Clarified that point-in-time audit statements do not replace the required period-of-time assessments. Mozilla continues to require full-surveillance period-of-time audits that must be conducted annually, and successive audit periods must be contiguous.

  • CAs are required to follow and be aware of discussions in the forum, where Mozilla's root program is coordinated, although they are not required to participate.

  • CAs are required at all times to operate in accordance with the applicable Certificate Policy (CP) and Certificate Practice Statement (CPS) documents, which must be reviewed and updated at least once every year.

Please confirm that you have reviewed version 2.5 of Mozilla's Root Store Policy, and that your CA's practices and CP/CPS documents are fully compliant with this version of Mozilla's Root Store Policy. (Required)

Use this space to express concern or qualification about your CA's full compliance with version 2.5 of Mozilla's Root Store Policy.

ACTION 2: Ensure that your non-technically-constrained** intermediate certificates are disclosed in the CCADB within one week of certificate creation, and before any such subordinate CA is allowed to issue certificates, as described in Mozilla's Root Store Policy.

** Please see ACTION 1 regarding the change in what it means for a certificate to be technically-constrained.

Any new intermediate certificate that is not added to the CCADB within the required time frame could be added to OneCRL.

We would like to remind CAs that Mozilla's Root Store Policy says: "CAs SHOULD NOT assume that trust is transferable." And it is Mozilla's expectation that CAs will not be issuing many externally-operated non-technically-constrained intermediate certificates. We intend to update Mozilla's Root Store Policy to require CAs to notify Mozilla of all new externally-operated non-technically-constrained subordinate CAs before issuing such certificates. Discussion about this change will happen in the forum.

Please confirm that your CA understands the above listed requirements for disclosure of intermediate certificates. (Required)

Use this space to express concern or qualifications about Mozilla's requirement on disclosure of intermediate certificates.

ACTION 3: All CAs are required to update their audit, CP, CPS and test website information in the CCADB for their certificate hierarchies at least annually. CAs are expected to maintain their intermediate certificate records themselves and to directly enter the corresponding updated audit statements. However, CAs cannot directly modify data for their root certificate records, because the data must first be verified by a root store operator.

To provide annual updates for included root certificates, CAs will create a single Audit Case for a particular set of audits (e.g. WebTrust CA, WebTrust BR, and WebTrust EV). Then the CA will create a set of corresponding Root Cases, one per root certificate, to tell the CCADB which certificates were in scope of that set of audits, and to update the corresponding test websites for each of those root certificates (when the websites trust bit is enabled).

Please carefully review the process for providing annual updates via an Audit Case in the CCADB. (Required)

Use this space to express concern or qualifications about Mozilla's annual update requirements.

ACTION 4: Work with your auditors to make sure you are getting full period-of-time audits (with no time gaps) and that your audit statements contain all of the required information. It is your responsibility, as the CA, to ensure that you have the appropriate audits performed and receive public-facing audit statements that meet Mozilla's requirements.

As stated in Mozilla’s April 2017 CA Communication and Mozilla’s Root Store Policy audit statements/letters must meet the following requirements or Mozilla will reject the audit statements. These requirements apply to ETSI and WebTrust audit statements. CAs without proper and current audit statements will be put on notice and potentially removed from Mozilla’s Root Store.

Additionally, audit statements must be provided in English from now on.

As a reminder, here is what Mozilla’s Root Store Policy says:
“Full-surveillance period-of-time audits MUST be conducted and updated audit information provided no less frequently than annually. Successive audits MUST be contiguous (no gaps).
The publicly-available documentation relating to each audit MUST contain at least the following clearly-labelled information:
- name of the company being audited;
- name and address of the organization performing the audit;
- Distinguished Name and SHA256 fingerprint of each root and intermediate certificate that was in scope;
- audit criteria (with version number) that were used to audit each of the certificates;
- a list of the CA policy documents (with version numbers) referenced during the audit;
- whether the audit is for a period of time or a point in time;
- the start date and end date of the period, for those that cover a period of time;
- the point-in-time date, for those that are for a point in time;
- the date the report was issued (which will necessarily be after the end date or point-in-time date); and
- For ETSI, a statement to indicate if the audit was a full audit, and which parts of the criteria were applied, e.g. DVCP, OVCP, NCP, NCP+, LCP, EVCP, EVCP+, QCP-w, Part1 (General Requirements), and/or Part 2 (Requirements for trust service providers).

The above listed information MUST be provided by the auditor in each audit statement or its accompanying letter. If the information is provided in an accompanying letter, then the PDF file that is submitted to Mozilla must contain BOTH the audit statement and the letter.

Please indicate your CA’s understanding that each audit statement/letter provided to Mozilla must be in English and must meet the requirements of Mozilla’s Root Store Policy, specifically stating the information listed above. Otherwise Mozilla will reject the audit statement, and put the CA on notice for being out of compliance, which may result in the CA’s root certificate(s) being removed from our program. (Required)

Use this space to express concern or qualifications about your response regarding content that MUST be included in audit statements/letters.

ACTION 5: Perform a BR Self Assessment and send it to Kathleen by January 31, 2018. Your BR Self Assessment must cover your CA Hierarchies (and all of the corresponding CP/CPS documents) that chain up to your CA's root certificates that are included in Mozilla's root store and enabled with the Websites trust bit.

Mozilla has added a requirement to our root inclusion/update process that CAs perform a BR Self Assessment. This will continue to be part of our root inclusion/update process. We have found this to be useful for ensuring that CAs are aware of the current CA/Browser Forum's Baseline Requirements. Therefore, we are requesting that each CA perform a BR Self Assessment if they have not already completed one. Our expectation is that CAs will update their processes and documentation to resolve any short-comings that are found during their BR Self Assessment.

Mozilla's Root Store Policy requires CAs to review and update their CP/CPS documents at least once every year, and to ensure that they remain fully compliant with the BRs. Therefore, we recommend that you perform a BR Self Self Assessment on a periodic basis.

Please indicate your plan to complete your CA's BR Self Assessment. (Required)

Use this space to explain your response regarding performing a BR Self Assessment.

ACTION 6: Check your CA's "Recognized CAA Domains" and "Problem Reporting Mechanism" fields in the CCADB, or in this spreadsheet, which is available at

Note that in the spreadsheet the email addresses have been slightly obfuscated by substituting '@' with "[at]" and '.' with "[dot]".

Mozilla requires that at least one of the mechanisms defined for Problem Reporting be an email address. Make sure that the CCADB has the correct email address for Problem Reporting, and test that this email address works and is connected to people or systems such that a timely response to a security incident can be expected 24/7. (Required)

Provide corrections to your CA's "Recognized CAA Domains" and "Problem Reporting Mechanism" data in the CCADB here.
If you have not defined at least one CAA domain, please explain why.

ACTION 7: Ensure your CA is aware of current discussions in the CA/Browser Forum about Certification Authority Authorization (CAA) . As of September 8, 2017, CAA Checking is Mandatory. Publication of CAA Resource Records allows a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis‐issue.

- currently permits both with and without errata CAA checking
- currently allows Errata ID 5065 and 5097
- supports the "natural" interpretation of the DNAME rules

If the CA/Browser Forum mandates CAA checking with-errata, then Mozilla will expect a migration within 3 months.

Please confirm that your CA will follow discussions about CAA, and will comply with "Effective Dates" regarding CAA as they are established. (Required)

Use this space to express concern or qualifications about your response regarding Certification Authority Authorization (CAA) .

ACTION 8: Check for issuance of certificates containing .tg domains from October 25 to November 11, 2017.

We believe that the .tg Registry was compromised from October 25 to November 10, 2017, such that a perpetrator set the Name Server (NS) Records for some domains to name servers controlled by them, and then successfully obtained certificates for those domains.

Please check the certificates containing .tg domains that chain up to your root certificates included in Mozilla's program to ensure that the certificate subscriber actually owns the domains included in their certificate. (Required)

Use this space to provide further information about certificates issued for .tg domains from October 25 to November 11, 2017.