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.
- This file lists the information that the CA must provide: File:CAInformationExample.pdf
- Watch for email from firstname.lastname@example.org containing additional requests for information.
- It is recommended that you add email@example.com 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 firstname.lastname@example.org.
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 (e.g. ….mac.dmg for an Apple system). Install (e.g. by clicking on the .dmg file and following the instructions).
- 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 Windows: Pull down the Tools menu and select Options…
- On Mac: Pull down the Firefox menu (or name of the test build, e.g Nightly) and select Preferences...
- On Linux: Pull down the Edit menu and select Preferences
- Select Advanced
- Select Certificates
- 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…” 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.
Recommendation: I find the "Cert Viewer Plus" Add-On useful for doing this type of testing. After you've installed this add-on, you can open the Certificate Manager from the Tools menu with one click. Also, when you browse to a website and click on the lock to view the details of the certificate chain, it displays the trust bit settings for the root. Additionally, the SHA-1 fingerprint in the Certificate Viewer can be selected and copied.
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.