CA/Certificate Change Process

Changing a Root Certificate that is Currently Included in NSS

This page describes how to change the default settings of a root certificate that is currently included in NSS.

Reasons to change a root certificate in NSS may included, but are not limited to:

• Security Compromise
• Add a Trust Bit (one of Websites, Email)
• Enable EV
• Disable a Root (turn off one or more of the trust bits)
• Remove a Root

Security Compromise

When a serious security concern is noticed, such as a root compromise, it should be treated as a security-sensitive bug, and a secure bug should be filed in Bugzilla.

To report a concern about certificates being issued by a CA in Mozilla's Program:

• https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&version=other

Open CA Mis-Issuance and other compliance bugs: https://wiki.mozilla.org/CA/Incident_Dashboard

Add a Trust Bit

When a root certificate is included in NSS, one or more of the trust bits (websites, email) are enabled. It is common for a CA to request inclusion with one of the trust bits enabled, and then later request that the other trust bit be enabled. The following steps outline how a CA may request to enable an additional trust bit for a root certificate that is included in NSS.

1. Do some initial preparations before you formally submit a request:
   • Update the CP/CPS to reflect the policies for the additional trust bits, and make sure that the additions to the CP/CPS follow Mozilla's Root Store Policy.
   • Review Required Practices and Forbidden Practices.
   • Have the annual audit cover the updated CP/CPS.
   • Make sure that the audit and audit statements meet the requirements stated in Mozilla's Root Store Policy.
2. Once you are ready, formally submit your request
   • Click on the "Create a new bug report" link in Application Instructions.
   • Set the bug summary to "Enable trust bits for <name of your root>".
   • Provide all of the required information by creating a Root Inclusion Case in the CCADB.
3. The request will go through the Information Verification, Detailed Review, Public Discussion, and Inclusion phases as described in Application Process Overview.

Enable EV

The following steps outline the procedure for a CA to request that Extended Validation (EV) treatment be enabled for a root certificate that is currently included in NSS.

1. Do some initial preparations before you formally submit a request:
   • Update the CP/CPS to reflect the EV policies, and make sure that the additions to the CP/CPS follow Mozilla's Root Store Policy as well as the CA/Browser Forum's EV SSL Certificate Guidelines.
   • Review Required Practices and Forbidden Practices.
   • Complete an EV audit that meets the requirements stated in Mozilla's Root Store Policy.
2. Once you are ready, formally submit your request
   • Click on the "Create a new bug report" link in Application Instructions.
   • Set the bug summary to "Enable EV for <name of your root>"..
   • Provide all of the required information by creating a Root Inclusion Case in the CCADB.
   • Run the EV-Readiness Check.
3. The request will go through the Information Verification, Detailed Review, Public Discussion, and Inclusion phases as described in Application Process Overview.

Remove or Disable a Root

Disabling a Root means one or more of the following:

• Turn off trust bits (Websites, Email)
• Turn off EV Treatment
• Distrust certificates issued after a certain date (Distrust for TLS After, Distrust for S/MIME After)

Reasons for removing or disabling a root certificate may include:

• Security Compromise
• Expired or Expiring CA
• Small modulus key length
• Outdated signing key algorithm
• Transition/Rollover to new root completed
• Legacy, no longer in use
• No recent audit

Important: Root changes that are motivated by a serious security concern such as a root compromise should be treated as a security-sensitive bug, and a secure bug filed in Bugzilla.

Otherwise, the ordinary or usual process for removing or disabling a root in NSS is as follows:

1. Initiate the request:
   • File a bug in Bugzilla with the following information:
     • Product: CA Program
     • Component: CA Certificate Root Program
     • Summary should be one of:
       • Remove <CN or cert name> root cert
       • Turn off Trust Bit(s) for <CN or cert name> root cert
       • Turn off EV Treatment for <CN or cert name> root cert
       • Set Distrust After for <CN or cert name> root cert
     • Description: Include the following information
       • Subject/Issuer field values in the root certificate to be changed
       • SHA256 Fingerprint of the certificate to be changed
       • Specify the change to be made. e.g. if the root is to be removed, or which trust bits are to be turned off, or the distrust-after dates
         • Consideration: For a serious situation, it might be better to disable the trust bits of that root, rather than just remove the root. If the root is removed, it could potentially be signed by another root that is included in NSS. However, if we disable the trust bits by default, then that root could not be used again for TLS in Firefox unless a user specifically turned on the websites trust bit for it.
       • Reason for requesting this change
       • Impact that the change may have on Mozilla users
   • The bug may be marked as security-sensitive. Security-sensitive bugs can be viewed only by a select set of Bugzilla users, not by the general public.
     • The security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update changing the trust bits of the root.
   • In most situations, an authoritative representative of the CA must request or approve the change. Mozilla reserves the right to approve the change without the consent of the CA.
2. The bug will be assigned to the Mozilla representative who is appointed to evaluate the request. This will usually be the CA Certificates Module Owner.
3. The Mozilla representative will ensure the necessary information has been provided.
   • Options should be identified
     • Which trust bits to unset (Websites, Email)
     • Whether the root certificate should be removed from NSS instead of unsetting trust bits
   • Technical assistance may be requested
   • Additional information may be requested of CA and other parties
   • The Mozilla representative must confirm that a qualified representative has approved the change. A qualified representative is either
     • The known representative of the CA, or
     • Two Mozilla staff members, if the CA is not in agreement.
4. The Mozilla representative will deliver any preliminary decisions
   • It may be necessary to treat the bug as a sensitive security issue and follow the Mozilla Policy for Handling Security Bugs or the root program's security incident reporting process.
5. Implementation
   • If the resulting decision is to change the root certificate, the Mozilla representative will create a corresponding NSS bug to make the actual changes in NSS, and mark that bug as blocking the original change request.
   • A Mozilla representative makes the changes in an NSS branch, and requests code review.
   • A Mozilla representative commits the changes into NSS, and marks the bug RESOLVED FIXED.
   • A Mozilla representative confirms the changes in Firefox Nightly, then updates the corresponding records in the CCADB.
   • For security-sensitive bugs, the security update will proceed as described in Mozilla's Policy for Handling Security Bugs
   • For non-security-sensitive requests, some time after the bug is marked as RESOLVED FIXED, various Mozilla products will move to using a version of NSS which contains the change. This process is mostly under the control of the release drivers for those products.
6. Notification
   • The CA is responsible for providing appropriate notification to users who may be impacted by the change.
   • For Security-sensitive requests the security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update removing the root.