Instructions for CAs
This page provides instructions to CAs for specific parts of Mozilla's application process for root inclusion and update requests. See the Application Process Overview for the list of the steps in the application process.
Create Root Inclusion/Update Request
An official representative of the CA may submit their request using Mozilla's Bugzilla issue tracking system:
- If you don't already have a Bugzilla account, create an account for yourself.
- Note that you must supply an email address when creating an account; this address will be made public, and will be used for communications, related to your request.
- Be sure to use an email address that you regularly monitor, because all communication regarding the request will be sent to this email address.
- Create a new bug report corresponding to your request.
- Product: NSS
- Component: CA Certificate Root Program
- Severity: enhancement
- Summary: Add [your CA's name] root certificate(s)
- Do NOT select the check boxes to restrict visibility, such as making it confidential or marking it as a security bug. All information that is submitted for root inclusion and update requests must be publicly available.
- Provide all of the information that is listed in the CA Information Checklist. This may be done by adding comments and attachments after the bug has been created.
- Template (Google Doc)
- Example (PDF)
- Note that the certificate data will be extracted directly from the PEM of the certificate, so the CA should attach the PEM of the root certificate to the Bugzilla bug, or provide a link to the certificate on their website.
- 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 the Bugzilla bug report.
- Watch for email from email@example.com containing additional requests for information.
- It is recommended that you add firstname.lastname@example.org to your email contacts so that notifications of updates to your bug don't get filtered into your SPAM folder.
IMPORTANT: Note that all information submitted to our Bugzilla system is publicly available to anyone on the Internet. Please do not include proprietary or confidential information in your request. If you wish to discuss confidential or sensitive matters, please do so via private email to email@example.com.
Here are the steps that a representative of the CA should take when asked to test that the certificate has been correctly imported and that websites work correctly.
- Click on the test build link that is provided, choose the download file for the operating system you are using.
- For Testing on Mac:
- Find the line with OSX that contains tc(B).
- Click the green B inside that tc(B), and the bottom part of the page will change to show more details of that build.
- In the right hand colum, you see several "artifact uploaded" entries.
- Scroll down that list to find "target.dmg". That's the Mac disk image that you're looking for.
- For Testing on Mac:
- It is very important to ensure that you test using a fresh profile in order to make sure you really seeing the trust bits provided by the test build, rather than the trust settings that you had set manually in an application profile. For more information about using a separate profile for testing, refer to the knowledge base articles: Profile Manager and Creating a new Firefox profile.
- Using a fresh profile is the best way to test, but you can also restore the default certificate settings as described here: https://wiki.mozilla.org/CA:UserCertDB#How_To_Restore_Default_Root_Certificate_Settings
- When you restart Firefox, be sure to use the test build that you just downloaded and installed. It will have a different name, like "Nightly" or such.
- If you are running Mac OS X 10.8 Mountain Lion, OS X, you may need to change the Gatekeeper settings to allow 3rd party apps to be run. For details see bug 1090459.
- If you are running Mac OS 10.12 Sierra or later, Apple removed the user interface for running unsigned applications. So, you can test the try build by opening a Terminal window (Applications->Utilities->Terminal.app) and typing: "sudo spctl --master-disable". You will have to enter your system password. Be sure to type "sudo spctl --master-enable" when you are done, to reset back to the regular protection. For details see bug 1352203.
- Check that your root certificate is included and the trust bits set correctly.
- Open the Options/Preferences window:
- On Mac: Pull down the Firefox menu (or name of the test build, e.g Nightly) and select Preferences...
- Select Privacy & Security
- Scroll down to the 'Certificates ' section
- Click on 'View Certificates' to open the Certificate Manager
- Select Authorities
- Find your root certificate and confirm that it is marked as "Builtin Object Token" in the Security Device column.
- Click on your root certificate to highlight it, then click on “Edit Trust…” to verify that the correct trust bits are checked.
- Open the Options/Preferences window:
- Browse to websites that have SSL certs that chain up to this root cert. The appropriate UI should appear indicating it is a secure website. Click on the lock and View Certificate, to see details.
- Comment in the bug to indicate your testing results.
Note: EV-enablement is done in a separate bug, after the root has been included.
Common CA Database
CAs are required to:
- Annually provide public-facing statement(s) of attestation of their conformance to the stated verification requirements.
- Notify Mozilla when its policies and business practices change in regards to verification procedures for issuing certificates, when the ownership control of the CA’s certificate(s) changes, or when ownership control of the CA’s operations changes.
- Ensure that Mozilla has their current contact information.
Additionally, CAs must maintain their data in the Common CA Database about:
- All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla’s CA Certificate Program that are not technically constrained via EKU and name constraints.
- Revoked certificates that were capable of being used to issue new certificates, and which directly or transitively chain to their certificate(s) included in Mozilla’s CA Certificate Program and were not technically constrained via EKU and name constraints.