Information checklist for CAs applying for inclusion in Mozilla
In order to support cryptographic applications such as SSL/TLS connections to web and other servers, and signed and encrypted email, Firefox and other Mozilla-based products contain digital certificates and related metadata for multiple Certification Authorities (CAs). By including the CA certificates and various associated pre-set metadata values Mozilla-based products can recognize as valid the end entity certificates that are issued under the auspices of the CAs in question and are associated with, e.g., web servers, and email senders.
Example and Template
The example and template below list the information that must be provided by the CA in their root inclusion or update request as per step 1 of Mozilla's Application Process.
- Example -- This is what it will look like when you create a Root Inclusion Case directly in the CCADB.
- Template (Google Doc) -- This template is no longer used. As of June 1, 2019, all CAs directly create their own Root Inclusion Case in the CCADB.
Mozilla's process is public-facing, so all information that will be taken under consideration during the root inclusion request must be publicly available and provided by the CA via a Case in the CCADB and in a Bugzilla bug report. (Both must be created as they will reference each other.)
Create a Root Inclusion Case
If your CA does not yet have access to the CCADB, then you may request access here:
If your CA currently has access to the CCADB, then enter your information directly as described below.
Note: The process for creating a Root Inclusion Case is very similar to the process shown in the video about creating an Audit Case.
- Login to the CCADB.
- Create a Root Inclusion Case in the CCADB - one Case per set of audit statements. (One Root Inclusion Case may consist of multiple roots, if they are covered by the same audit statement.)
- Click on the 'My CA' tab
- Scroll down to the 'Cases' section
- Click on the 'New Case' button, and select "CA Root Inclusion Request"
- Click on the 'Submit' button to create the new Root Inclusion Case.
- For our use, the 'Submit' button is the ‘Save’ button. (Salesforce doesn’t currently let us change the name of this particular button.)
- You may click on 'Edit' and 'Submit' as many times as you need to get all of your information entered.
- Click on the 'Copy Audit Info' button, to copy data from a root certificate already in the CCADB (if applicable).
- Otherwise click on the 'Edit' button, enter the Auditor and Audit statement information, then click on the 'Submit' button.
- Audit statements must meet the requirements listed in section 5.1 of the Common CCADB Policy
- CCADB automatically converts WebTrust Seal URLs into PDF URLs when you click on ‘Submit’
- Click on the 'Add/Update Root Cases' button to add each PEM for each new root certificate or to indicate which existing root certificates are part of this root inclusion or update request.
- For each root certificate to be considered in your request, check the boxes corresponding to the audit statements that apply. Then click on the 'Apply Changes' button. This will create corresponding Root Cases.
- Click on the 'Update Policy Documents' button to provide current CP/CPS information.
- Click on the 'Help' button in the 'Add Policy Documents' page for instructions
- Update existing policy document information, or add new policy documents via the 'Add Policy Document' button
- Click on the checkmark to save each set of changes before clicking on the ‘Go Back’ button to return to the Case
- Click on the ‘Edit Test Websites’ button to enter the test websites for new root certificates if you are requesting the Websites (TLS/SSL) trust bit.
- Click on the 'Test Websites Validation' button, resolve all failures, then click on 'Re-run Validation'
- Click on the ‘Audit Letter Validation [ALV]’ button, and work with your auditor to resolve all problems.
- Fill in the remaining information in your Case and Root Cases. Fill in your responses for each field where there are "NEED" statements.
- Scroll down to the 'Mozilla Additional Requirements' section and click on the 'Print NEED Fields' to see where further information is needed.
- Click on the 'Get URLs' button and copy the line that begins with “Mozilla Root Inclusion Case Information:” into a Comment in your Bugzilla Bug. The line to copy and paste into the Bugzilla Bug looks like:
- Mozilla Root Inclusion Case Information: https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000341
- This will trigger step 2 of Mozilla’s root inclusion process.
- Whenever you update data in your Root Inclusion Case in the CCADB, be sure to add a comment to your Bugzilla Bug to let folks know to re-check the information.
- Fields for which a root store operator has set "Data Verified" cannot be edited until you ask the root store operator to change the corresponding status back to "Not Verified".
CA Primary Point of Contact (POC)
In addition to the information listed in the template and example above, CAs must provide the contact information for at least one person filling the role of Primary Point of Contact (POC), and may use a contractor as one of the POCs. The CA must have one or more people within the CA’s organization who jointly have authority to speak on behalf of the CA, and to direct whatever changes the review process or Mozilla’s CA Communications require. At least one of the CA’s POCs should also be in a position to make commitments for the CA and be held accountable by the CA.
The POCs will:
- Provide annual updates of CP/CPS documents, audit statements, and test websites.
- Respond to CA Communications
- Input and maintain the CA’s data in the Common CA Database (CCADB)
- Inform Mozilla when there is a change in the organization, ownership, CA policies, or in the POCs that Mozilla should be aware of, as per
- Provide Mozilla with updated contact information if a new person becomes a POC.
Required contact information:
- Direct E-mail address, full name (first and last name), and phone number to a specific individual within the CA (must be one of the POCs).
- CA Email Alias: An email alias is being requested so that more than one person in your organization will receive notifications in case the primary contact is out of the office or leaves the organization. Mozilla CA Communications will be sent to both the POC direct email address(es) and the email alias.
- CA Phone Number: A main phone number from which Mozilla can reach the organization responsible for root certificates for the CA.
- Title / Department: If Mozilla needed to call your main phone number, what Title/Department should the Mozilla representative ask for?
If the CA uses a contractor as an additional POC, then someone at the CA must be CC’d on the root inclusion Bugzilla bug, CA Communications, and the CA’s responses to CA Communications.
- An individual within the CA must also get a Bugzilla account and comment in the bug to say that they will be a POC for the CA, and that the contractor has indeed been hired by the CA to act as one of the POCs.
To ensure that the POC(s) has the authority to perform the tasks listed above, a representative of Mozilla will do the following.
- Use the CA’s website, to confirm that the domain in the email address of at least one of the POCs is owned by the CA (e.g. @CAname.com).
- Use the CA’s website to contact a person at the CA to confirm that at least one of the POCs that have been provided does indeed have the authority to perform the responsibilities listed above on behalf of the CA.
- If a contractor is also used as a POC, then contact the POC that was previously verified to confirm that the CA has indeed enlisted the help of the contractor.