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 Code Signing)
• 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 major root compromise, it should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed.

Add a Trust Bit

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

1. Update the CP/CPS to reflect the policies for the additional trust bits, and make sure that the additions to the CP/CPS follow the Mozilla CA Certificate Policy, especially section 7.
2. Also see the Recommended Practices and Potentially Problematic Practices.
3. Have the annual audit cover the updated CP/CPS.
   • Make sure that the audit meets the requirements stated in the Mozilla CA Certificate Policy.
4. File a bug by clicking on the "Create a new bug report" link in CA:How_to_apply.
   • Change the bug summary to "Enable trust bits for <name of your root>".
   • In the bug description add a reference to the original root-inclusion bug number.
   • In the bug description include links to the updated CP/CPS and the updated audit.
5. The request will go through the Information Gathering and Verification, Public Discussion, and Inclusion phases as described in CA:How_to_apply.

Enable EV

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

1. Update the CP/CPS to reflect the EV policies, and make sure that the additions to the CP/CPS follow the Mozilla CA Certificate Policy as well as the EV SSL Certificate Guidelines Version 1.2 that are posted on the CA/Browser Forum website.
2. Also see the Recommended Practices and Potentially Problematic Practices.
3. Complete a WebTrust EV audit that meets the requirements stated in the Mozilla CA Certificate Policy.
4. File a bug by clicking on the "Create a new bug report" link in CA:How_to_apply.
   • Change the bug summary to "Enable EV for <name of your root>".
   • In the bug description add a reference to the original root-inclusion bug number.
   • In the bug description include links to the updated CP/CPS and the WebTrust EV audit.
5. The request will go through the Information Gathering and Verification, Public Discussion, and Inclusion phases as described in CA:How_to_apply

Disable a Root

Disabling a root is the act of turning off one or more of the three trust bits (Websites, Email, Code Signing).

Reasons for disabling a root certificate may include, but are not limited to:

• Expired or Expiring CA
• Small modulus key length; NIST recommendations about phasing out 1024 bit roots
• Outdated signing key algorithm; e.g. MD2/MD5
• Transition/Rollover to new root completed
• Legacy, no longer in use
• No recent audit

The process for disabling a root in NSS is as follows:

1. Initiate the request
   • File a bug in Bugzilla with the following information:
     • Product: mozilla.org
     • Component: CA Certificates
     • Summary: Disable (CN or cert name) root cert
     • Description: Include the following information
       • Value of the O (Organization) and OU (Organizational Unit) fields in the root certificate to be changed
       • The certificate Common Name and or Certificate Name
       • If needed, other information to clearly identify which root is to be changed (eg SHA1 Fingerprint)
       • Which trust bits are to be turned off
       • 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 standing 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, Code Signing)
     • Versus complete removal of the root cert from NSS
   • Technical assistance may be requested
   • Additional information may be requested of CA and other parties
   • The Mozilla representative must confirm that a qualified representative of either the CA or Mozilla has either requested or approved the change.
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
5. The Mozilla representative will start a public discussion in the mozilla.dev.security.policy newsgroup.
   • Outline is presented, references to full bug provided
   • Deadline for discussion is set
   • Security-sensitive requests for root changes would be discussed primarily within the (closed) Mozilla security group. However others could be added to the discussion by explicitly cc-ing them on the bug.
6. The Mozilla representative will summarize the discussion and communicate the decisions in the bug.
   • Decision about which Trust Bits to unset
   • Any other options or actions as decided
7. 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 creates a test build of NSS with the change to the root certificate, and attaches nssckbi.dll to the bug. A representative of the CA or of Mozilla must download this, drop it into a copy of Firefox and/or Thunderbird and confirm (by adding a comment in the bug) that the certificate has been correctly changed.
   • A Mozilla representative checks the changes into the NSS store, and marks the bug RESOLVED FIXED.
   • 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.
8. 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.

Remove a Root

Reasons for removing a root certificate may include, but are not limited to:

• Security Compromise
  • Root removals that are motivated by a serious security concern such as a major root compromise should be treated as a security-sensitive bug, and the Mozilla Policy for Handling Security Bugs should be followed.
• Expired or Expiring CA
• Small modulus key length (e.g. 1024-bit or smaller)
• Outdated signing key algorithm (e.g. MD2 or MD5)
• Transition/Rollover to new root completed
• Legacy, no longer in use
• No recent audit
• Previously deprecated

Note: For some root certificates it may be better to turn off the websites trust bit and leave one or both of the email and code singing trust bits enabled. The Disable a Root section above explains how to request that specific trust bits be turned off for a root certificate.

The process for removing a root from NSS is as follows:

1. Initiate the request
   • File a bug in Bugzilla with the following information:
     • Product: mozilla.org
     • Component: CA Certificates
     • Summary: Remove (CN or cert name) root cert
     • Description: Include the following information
       • Value of the O (Organization) and OU (Organizational Unit) fields in the root certificate to be changed
       • The certificate Common Name and or Certificate Name
       • If needed, other information to clearly identify which root is to be changed (eg SHA1 Fingerprint)
       • Reason for requesting that the root be removed
       • Impact that removing the root 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 removing 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 standing module owner.
3. The Mozilla representative will ensure the necessary information has been provided.
   • Options should be identified
     • Complete removal of the root cert from NSS versus turning off specific 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 of either the CA or Mozilla has either requested or approved the change.
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
5. The Mozilla representative will start a public discussion in the mozilla.dev.security.policy newsgroup.
   • Outline is presented, references to full bug provided
   • Deadline for discussion is set
   • Security-sensitive requests for root removals would be discussed primarily within the (closed) Mozilla security group. However others could be added to the discussion by explicitly cc-ing them on the bug.
6. The Mozilla representative will summarize the discussion and communicate the decisions in the bug.
   • Decision about whether or not to remove the root certificate
   • Any other options or actions as decided
7. Implementation
   • If the resulting decision is to remove or 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 creates a test build of NSS with the change to the root certificate, and attaches nssckbi.dll to the bug. A representative of the CA or of Mozilla must download this, drop it into a copy of Firefox and/or Thunderbird and confirm (by adding a comment in the bug) that the certificate has been correctly changed or removed.
   • A Mozilla representative checks the changes into the NSS store, and marks the bug RESOLVED FIXED.
   • 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.
8. 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.