The internet secure communications system requires Certification Authorities (CAs) - parties trusted to attest to the identity of websites. Mozilla products ship a default list of CA certificates, which may change with each security patch or new version of the product. The following pages explain how the default list of CA certificates is managed.

Who May Apply

An official representative of the CA must make the formal request for inclusion or update of their CA's root certificates. If you would like to see a particular root certificate included in Mozilla products, then please contact the CA who operates that root certificate.

CAs must carefully consider whether their root certificate needs to be directly included in Mozilla's root store or if it would be better to be a subordinate CA of an already-included CA.

Mozilla's CA Certificate Policy states: "We will determine which CA certificates are included in Mozilla's root program based on the risks of such inclusion to typical users of our products." Including any CA carries a level of risk that is measured, in part, by the past record of the CA operator (or lack thereof), their responsiveness (or lack thereof), and the level of competence and precision demonstrated by the CA operator during the inclusion process. In some cases, a better alternative is to be a subordinate CA of a CA that is already included in Mozilla's root store.

It is the responsibility of new applicants to justify why their root certificate needs to be included in Mozilla's root store and to explain why the inclusion will not introduce undue risk for Mozilla users. See the Mozilla wiki page "Quantifying Value: Information Expected of New Applicants".

Having a root certificate you control included in Mozilla's root store is a major ongoing responsibility; it is not a one-time effort. It means that, in the normal case, the world will trust you to correctly issue digital certificates identifying any website and/or email address. There will be associated costs in maintaining the required security infrastructure, keeping up-to-date with evolving technical and procedural requirements, and conducting audits on an annual basis. After a CA operator has a CA certificate included in Mozilla's root store, it is expected that the CA operator will continue to be aware of ongoing discussions in the Mozilla dev-security-policy list and the CCADB discussion group and updates to Mozilla's Root Store Policy. The CA is required to submit regular program updates to Mozilla via the Common CA Database (CCADB), including annual updates to their policy and audit documentation.

Process Overview

This process is used to request any of the following:

• Include a new root certificate, even if the CA already has root certificates included in Mozilla's root store
• Include a renewed version or re-issued version of an already-included root certificate
• Enable EV treatment for an already-included root certificate
• Turn on additional trust bits for an already-included root certificate

Approval of one root certificate does not imply that other root certificates owned by the same CA operator would be accepted.

It typically takes up to two years for a new CA to make it from one end of the process to the other. If the CA does not provide requested information in a timely manner, then the application can take even longer, or may be cancelled.

The overall steps of the CA certificate inclusion and update process are as follows. There are Bugzilla Bug Whiteboard tags corresponding to many of these steps.

Parts of this root inclusion process are also set forth on the CCADB website.

1. A representative of the CA
   • Must review Mozilla's Root Inclusion Considerations before starting this process. Mozilla will reject root inclusion requests when the applying CA has engaged in any of the unnaceptable behaviors, or an aggregate of the concerning behaviors or warning signs.
   • Submits a request for root inclusion in both Bugzilla and in the CCADB (a representative of Mozilla issues a Common CA Database (CCADB) license to the Primary Point of Contact for the CA), and
   • Provides information about the CA and operation of the root certificate(s).
     • All information provided by the CA must be publicly available.
     • If the CA contracts to another organization to help with the root inclusion request, the representative of the CA must clarify that relationship in their request, and must provide clear information about who the ongoing points-of-contact will be for the CA.
     • New Applicants must submit a Value Justification.
     • All Applicants must have a CCADB Self Assessment that is not older than 365 days.
2. A representative of Mozilla or another Root Store Member of the CCADB confirms all information was provided by the CA.
   • Refer to "Prerequisites" to public discussion, which is conducted on the CCADB Public discussion list.
3. Public discussion for a six-week period begins on the CCADB discussion list. If no concerns are raised during that time period, then the discussion may close and the request may proceed to the "last call" and approval phases.
4. During the public-discussion phase, a representative of Mozilla, another Root Store Member of the CCADB, or the Community (as agreed by a Mozilla representative) may perform a detailed review of the CA’s CP/CPS and audit documents. During this phase, the CA may be required to update their CP/CPS and audit documents to become fully aligned with Mozilla's Root Store Policy.
   • Previous detailed reviews of CA CP/CPS and audit documents
5. A representative of the CA responds to questions and concerns posted during the public discussion of the CA's request. The CA also completes action items resulting from the public discussion, which may include updating processes, documentation, and audits.
   • If concerns are raised during the discussion about the CA having engaged in any Unacceptable Behaviors or a collection of the Concerning Behaviors, then the representative of the CA shall provide a public response to https://wiki.mozilla.org/CA/Root_Inclusion_Considerations.
   • A discussion may be extended beyond the initial comment period if concerns or questions are raised that require further attention.
   • A discussion may be put on hold, pending a CA action item, such that the discussion may continue as soon as the CA has provided the requested information.
   • A representative of Mozilla or another Root Store Member of the CCADB confirms the completion of the action items and continues public discussion if needed.
6. At the end of the six-week public discussion period, a representative of Mozilla or the Root Store Member who initiated the public discussion provides a summary within 5 business days noting any objections or open questions that did not receive a response from the CA owner and states the public discussion period has concluded.
   • If there are outstanding issues that need to be addressed (e.g., a need for further information, or concerns about CA practices) then the request may be closed, moved back to the Information Verification phase, or put on hold pending future discussion after the CA has addressed the concerns.
7. Following public discussion, a representative of Mozilla will post on the Mozilla dev-security-policy list and indicate Mozilla's intent to either approve or reject the inclusion request.
   • This is the last call for objection. After one week, if no further questions or concerns are raised, then a representative of Mozilla may approve the request, by stating so in the bug.
8. A representative of Mozilla creates a bug requesting the actual changes in NSS (and PSM for EV treatment).
9. A representative of the CA confirms that all the data in the NSS bug is correct.
10. A representative of Mozilla creates a patch with the new CA certificates and trust bit settings, and provides a special test version of Firefox.
    • Changes to NSS regarding CA certificate applications are usually grouped and done as a batch when there is either a large set of changes or about every 3 months.
11. A representative of the CA tests the code changes using the test version of Firefox and confirms (by adding a comment in the NSS bug) that the correct certificate(s) is/are included and that the trust bits are correctly set.
12. A representative of Mozilla requests that another Mozilla representative review the patch.
13. A representative of Mozilla adds (commits) the patch to NSS, then closes the NSS bug as RESOLVED FIXED.
14. Mozilla products move to using a version of NSS which contains the certificate changes. This process is mostly under the control of the release drivers for those products. See Mozilla's Release Calendar.
15. The CA enters data into the CCADB for:
    • All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their root certificate(s) included in Mozilla’s Root Store that are not technically constrained as described in section 5.3 of Mozilla's Root Store Policy; and
    • Revoked intermediate certificates that chain to their certificate(s) included in Mozilla's Root Store.

Ways You Can Help

Our most pressing need is help with reviewing and contributing to the public discussions of CA applications. Public discussions about root inclusions and most change requests take place in the CCADB public mailing list.