Personal tools

CA:How to apply

From MozillaWiki

Jump to: navigation, search

Contents

Applying for root inclusion in Mozilla products

This information is intended to help official representatives of Certification Authorities (CAs) applying to have root certificate(s) included in Mozilla products. Our goal is to make the process as straightforward as possible for CAs, while ensuring that CAs do everything needed for us to determine whether they meet the requirements of our Mozilla CA certificate policy.

The main phases involved in evaluating a root for inclusion in Mozilla products are

  1. Creation and submission of the CA root certificate inclusion request
  2. Information verification
  3. Public discussion
  4. Decision on inclusion
  5. Code change for inclusion and associated testing

IMPORTANT Items to Note:

  • The information listed in CA Information Checklist is expected to be publicly available so that it can be reviewed and referenced during the Public Discussion Phase and for future reference.
  • Having a root included in NSS is not a one-time effort. After a CA has a root included in NSS, it is expected that the CA will continue to be aware of ongoing discussions and updates to the Mozilla CA Certificate Policy. The CA is required to send regular updated audits to Mozilla. The CA is required to update their policies as the Mozilla CA Certificate Policy is updated.
  • According to the Mozilla CA Certificate Policy: "We will determine which CA certificates are included in software products distributed through mozilla.org, based on the benefits and risks of such inclusion to typical users of those products." and "We require that all CAs whose certificates are distributed with our software product ... provide some service relevant to typical users of our software products" It is the CAs responsibility to explain why their root needs to be included in NSS and explain how the inclusion will benefit typical Mozilla users.

Timeline

The following table shows the best case time and the typical time that it takes to complete each of the phases of the root inclusion process for a CA that is new to Mozilla's program. The best case scenario assumes that the CA responds within one day to each and every request, that all of the information in the CA Information Checklist has been provided, that the CA follows the Mozilla CA Certificate Policy and Recommended Practices, and that the CA doesn't have any Potentially Problematic Practices. The timeline shown for the typical case assumes that the CA responds to each request within two days, that there are only a small number of concerns that need to be addressed, and that all of the concerns that are raised are resolved promptly. Both timelines assume that an audit that meets the requirements of the Mozilla CA Certificate Policy is performed annually.

  • This timeline is subject to change, and may vary depending on the other entries in the queue, and on other priorities that the Mozilla representative has to work on.
Phase Best case ... Typical case
Information Verification 2 weeks 2 months
Queue for Public Discussion 6 months 6 months
First Public Discussion 2 weeks 4 weeks
Response to First Public Discussion not needed CA-specific
Second Public Discussion not needed 2 weeks
Formal approval 1 week 1 week
Inclusion in NSS 3 months 3 months
Inclusion in Firefox 2 months 2 months
Total ~12 months >15 months

IMPORTANT: These are hypothetical estimates, and are not promises or commitments regarding any specific CA's request.

Creation and submission of the root CA certificate inclusion request

An official representative of the CA must submit and/or participate in the root inclusion request. According to Mozilla's CA Certificate Inclusion Policy: "To request that its certificate(s) be added to the default set a CA should submit a formal request by submitting a bug report into the mozilla.org Bugzilla system ... The request must be made by an authorized representative of the subject CA..." If the CA contracts to another organization to help with the root inclusion request, the representative of the CA must clarify that relationship in the bug, and must provide clear information about who the ongoing points-of-contact will be for the CA.

The steps to create a complete root certificate request are as follows:

  1. Do some initial preparations before you formally submit a request:
    • Read through the Mozilla CA certificate policy to learn all the requirements for the certificate to be included in Mozilla products, and to determine if your CA is eligible.
    • Gather all of the information listed in CA Information Checklist. Your request will not be processed until all of this information is provided in a Mozilla Bugzilla bug as described below.
    • Read through the Recommended Practices for further explanation about the requirements for the certificate to be included in Mozilla products.
    • Review the list of potentially problematic CA practices that have caused issues with other CAs' applications, and determine whether any of them might apply to you.
    • Designate someone to be your official representative for purposes of your application. You should choose someone who is reasonably fluent in written English and familiar with the operations of the CA.
    • If you have questions about the policy or the evaluation process, please contact us at certificate@mozilla.org. We will be glad to discuss with you how the process works, and can give you informal advice on how to ensure that the process goes as smoothly as possible for you.
  2. Once you are ready, formally submit your request using the Mozilla project'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. The link just given will fill in many the multiple-choice fields correctly, and add templated text to the Summary and Description which you then need to replace with the appropriate information about your CA and your root(s).
      • If the link to create a bug report does not work for you, then follow the instructions in CA Information Template to manually create the bug and set the appropriate fields.
      • Do NOT select "Restricted Visibility" or "Role Visibility". All information that is submitted for Root Inclusion requests must be publicly available.
  3. 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.
  4. Watch for email from bugzilla-daemon@mozilla.org containing additional requests for information.
    • It is recommended that you add bugzilla-daemon@mozilla.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 certificates@mozilla.org.

Information Verification

In this phase someone working on behalf of Mozilla will review and verify the information that you have supplied. They will check to make sure that all of the information listed in the CA Information Checklist has been provided, as well as perform the following verification steps. They may ask for further information if it is needed. The duration of this phase depends on the completeness of the information provided in Bugzilla, and your responsiveness in providing further information when asked for it.

The person working on behalf of Mozilla will do the following for each root CA certificate that you wish to have included:

  1. Verify the information provided in response to the information checklist.
    • Download the root CA certificate in Firefox, and compare against the data provided.
    • Look for items of concern, such as:
      • X.509 certificate version not equal to 3.
      • For RSA public keys, modulus length of 1024 bit. (NIST recommends that all such roots be phased out by the end of 2010.)
    • Download the applicable CRL(s) in Firefox to verify that they load correctly.
    • Check the OCSP responder URL in Firefox, if one is provided.
    • For SSL certificates, try the website that has been provided for testing purposes, ensure that the lock icon is displayed, and double click on the lock icon and compare the data for the root that the cert chains up to, to the data that has been provided.
    • For other certificates, download the test cert and check the chaining and root information.
  2. Review the CP/CPS to
    • Look for a statement about the frequency of update for the CRLs for end-entity certificates chaining to this root.
    • Look for a statement about the maximum time until OCSP responders are updated to reflect end-entity revocation (if OCSP is enabled).
    • Ensure that there is text in the CP/CPS that demonstrates that you take reasonable measures to verify the following information for end-entity certificates chaining up to this root, as per section 7 of the Mozilla CA certificate policy.
      • For a certificate to be used for SSL-enabled servers, that you take reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;
      • for a certificate to be used for digitally signing and/or encrypting email messages, that you take reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf;
      • for certificates to be used for digitally signing code objects, that you take reasonable measures to verify that the entity submitting the certificate signing request is the same entity referenced in the certificate or has been authorized by the entity referenced in the certificate to act on that entity's behalf;
    • Identify if the SSL certificates chaining up to this root are DV and/or OV. Some of the potentially problematic practices, only apply to DV certificates.
      • DV: Organization attribute is not verified. Only the Domain Name referenced in the certificate is verified to be owned/controlled by the subscriber.
      • OV: Both the Organization and the ownership/control of the Domain Name are verified.
    • Look for potentially problematic practices, and request further information whenever one of these practices is applicable.
    • All documents supplied as evidence should be publicly available and must be addressed in any audit. Any substantial omissions submitted afterwards may need to be confirmed by auditor, at Mozilla's discretion.
  3. Review CA hierarchy information provided for this root (preferably in the form of both a diagram and a description).
    • Make sure that there is a clear list and/or description of the internally operated subordinate CAs chaining to the root. For internally-operated subordinate CAs the key is to confirm that their operation is addressed by the relevant CP/CPS, and that any audit covers them as well as the root.
    • Make sure there is a clear list and/or description of the subordinate CAs that are operated by third parties. Make sure there is a clear general description and an explanation as to how the CP/CPS and audits ensure the third parties are in compliance with our policy requirements as per the Subordinate CA Checklist.
      • Verify that contractual arrangements require third-party subordinates to operate in accordance with a CP/CPS.
      • Investigate applicable technical arrangements on subordinate CAs, including name constraints, not allowing subordinates to create their own subordinates, etc.
      • Determine the extent and nature of audits performed against subordinate CAs, including whether or not subordinate CAs are included within the scope of any audit(s) done against the root CA, whether or not subordinate CAs are subject to third-party audits independent of any audit(s) done against the root CA, and whether or not you perform your own audits of subordinate CAs.
      • Determine the frequency at which any audit(s) for subordinate CAs are done.
    • Determine any other root CAs that have issued cross-signing certificates for this root CA.
  4. Review audit documents to make sure that the requirements are met in regards to sections 11 through 14 of Mozilla's CA Certificate Inclusion Policy.
    • Make sure the audit isn’t more than a year old.
    • Verify that the audit was performed by an independent third party.
    • Verify that the audit covers the practices and requirements of ETSI TS 101 456 (only acceptable for non-SSL), ETSI TS 102 042, or WebTrust Principles and Criteria for Certification Authorities.
    • Review the audit report to flag any issues noted in the report.
    • Do an independent verification of the audit when the report is provided by or posted by the submitter, rather than being posted on a third-party site such as webtrust.org.
      • Look on the internet to verify that the auditor meets the policy requirements, and to find contact information for the auditor.
      • Using the contact information found on the internet, send an inquiry to the auditor to ask them to verify that the audit provided was indeed issued by them, and that the contents match the audit report that they issued.
  5. For requests to enable a root so that EV certificates may be issued under that root:
    • Verify the EV policy OID(s).
    • Make sure the CP/CPS incorporate (directly or by referenced) the EV Guidelines as published by the CAB Forum.
    • Make sure there has been audits within the past year for both EV and non-EV SSL certificate issuance that meet the requirements of Mozilla's CA Certificate Inclusion Policy.
    • If any of the subordinate CAs that are operated by third-parties are or will be EV enabled, refer to EV guidelines section 7.b.1 and section 37b. Also, provide audit requirements for these third-parties.

Once all of this data has been verified, the Mozilla representative will update the whiteboard section in the bug and the status of the corresponding entry in the pending CA request list will be updated to “Information confirmed complete”. The request will be prioritized and added to the Queue for Public Discussion. The bug will be updated when the request enters into the first public discussion.

Public discussion

The Mozilla project is a public project in which anyone may participate. We therefore include in our evaluation process a period for public comment during which interested parties may review the information you supply, ask additional questions regarding the CA, and provide their opinions on whether the request should be approved or not.

At present there are one or (optionally) two phases of public discussion. At the end of the first phase we will make a preliminary determination as to whether the request will be approved or not, based on the information supplied and the resolution of any new issues raised during phase 1 of public discussion. During the second phase of public discussion interested parties may make final comments, and after that phase ends we will make a final decision.

Who participates in the public discussions?
You! Members of the Mozilla community volunteer their time to review CA inclusion requests and provide their feedback. Participants should have knowledge of PKI, business practices, and policies. The more participants contributing to each discussion, the better the discussion will be in regards to ferreting out issues, helping the requester to improve their practices, and bringing the discussion to closure.

Note: If you have not contributed to a discussion before, wait no more! The more you contribute to discussions, the more you establish yourself as a knowledgeable and objective reviewer. Then when there is a request that you are particularly interested in providing feedback on, your contributions will be even more effective. Additionally, if you are a CA with a request in the queue, participating in other discussions is a great way to learn the expectations and be prepared for the discussion of your request.

What do reviewers look for?
Reviewers of CA inclusion requests look for anything which could be of concern to Mozilla.

  • Are all of the items listed in the Mozilla CA Certificate Policy addressed?
    • In particular, are there effective controls for certificate issuance and auditing of the same, which include:
      • Verification of domain control for webserver certificates
      • Verification of email address control for email certificates
      • Identification of legal entity for software certificates
  • Are the Recommended Practices followed?
  • Are there any Potentially Problematic Practices?
  • Are there previous recommendations that should be taken into consideration in this case?
  • Are there any potential risks that should be investigated?

Note: The official position of Mozilla might be different than the recommendations and suggestions of the reviewer. Reviewers are encouraged to contribute their recommendations and suggestions to the discussions. A representative of Mozilla will state when the official position of Mozilla differs from what has been posted in a discussion.

Where do the discussions take place?
Public discussions about root inclusion and change requests take place in the mozilla.dev.security.policy discussion forum.

It is recommended that you use a newsreader and not the web interface to Google Groups, because there have been recurring problems with messages that are posted to the discussion forum not getting propagated to Google Groups. Additionally there have been recurring problems where posts to the discussion forum via the Google Groups interface are not sent.

Will my input be viewed as representing my employer?
A representative of the CA whose root inclusion request is being discussed must clearly represent their employer and must promptly respond directly in the discussion thread to all questions that are posted.

All other contributors to the discussion may choose between representing their employer or not. When you post your input into the discussion, you may choose to use a non-work-related email address and/or add a note in your signature stating that the views/comments posted therein are of your opinion only, and do not represent the views/opinions of the company your work for. On the other hand, some contributors prefer to use their work email address and provide their input as an employee representing their employer. It’s up to you.

How long does a discussion take?
The time that each discussion takes varies dramatically depending on the number of reviewers contributing to the discussion, and the types of concerns that are raised. If no one reviews and contributes to a discussion, then a request may sit in the discussion for weeks. If you have a request in the Queue for Public Discussion, then you are directly impacted when there are not enough people contributing to the discussions ahead of yours.

How can you help?

You can help by reviewing and providing your feedback in each public discussion of root inclusion requests, or by asking a colleague to do so.

For each discussion for a CA that is new to Mozilla's program, there must be input from at least two people who have reviewed and commented on the request. The comment can be questions, requests for clarification, or statements about items that you find concerning with respect to how the CA follows the Mozilla CA Certificate Policy. The comment can also be as simple as “I have reviewed this request and find nothing of concern” (if that is indeed the case).

Phase 1 of public discussion

To begin this phase, a representative of Mozilla will create a new discussion thread in the mozilla.dev.security.policy newsgroup and will post information to the associated bug that the public discussion has begun.

Here is how a typical discussion proceeds:

  1. The Mozilla representative starts the discussion by providing a summary of the request, and a summary of the information about the CA's practices.
  2. People from the Mozilla community reply in the discussion to ask questions and comment on the request.
  3. A representative of the CA replies to the questions and comments in the discussion thread. This may result in further discussion. Others from the Mozilla community may add their opinions and ask more questions.
  4. Once the question/answer discussions have begun to reach conclusions, then a representative of the CA may propose changes to make to the CP/CPS to address the concerns. This may result in further discussion.
  5. After the discussions have resulted in a clear set of things to update in the CP/CPS and possibly operational practices, then the Mozilla representative will close the discussion and track the action items in the bug. When the CA has completed the action items, and the Mozilla representative has confirmed that the action items have been completed, the Mozilla representative may start a second round of discussion.

You are expected to participate directly in this discussion, by responding to questions raised in the newsgroup and/or posting comments to the bug. The discussion is public, so please ensure that any information provided is not proprietary or confidential. The more active you are in responding to inquiries within the discussion, the more productive the discussion will be.

At the end of the first public discussion phase, the Mozilla representative will post a summary in the bug about the results of the discussion and the open action items. Technical concerns, information about subordinate CAs (particularly those operated by third-parties), and potentially problematic practices will be specifically stated. The resulting information will vary depending on what issues or items of note have been found.

If there are no open issues or action items after the first discussion period, and there is general agreement that you comply with our policy requirements, then at Mozilla's discretion the second phase of public discussion may be skipped. The Mozilla representative will post a summary and recommendation in the bug using the following template.

https://wiki.mozilla.org/CA:Tentative_approval_template

Then a representative of Mozilla may approve the request by noting approval in the bug, after which, the request will move into the inclusion phase as described below.

Otherwise the Mozilla representative will list the action items that must be completed before the second phase of public discussion can begin.

Response to public discussion

Frequently there will be follow-up actions to be performed after the first public discussion phase, and the Mozilla representative may decide to postpone further public discussion until you address particular issues or provide additional information. The duration of this postponement is dependent on how long it takes to complete the action items. You should post updates to the action items in the bug. When the action items are completed, you should work with the Mozilla representative to get scheduled for phase 2 of public discussion.

Phase 2 of public Discussion

This phase is very similar to the first phase of public discussion. To begin this phase, a representative of Mozilla will create a new discussion thread in the mozilla.dev.security.policy newsgroup and will post information to the associated bug that the public discussion has begun.

Interested members of the general public may provide comments and ask questions, and you should respond to any material issues or questions raised by participating directly in the discussion.

At the end of the public discussion phase 2, the Mozilla representative will post a summary in the bug about the results of the discussion and the open action items. If there are no open issues or action items after the second discussion period, and there is general agreement that you comply with our policy requirements, then at Mozilla's discretion the Mozilla representative will post a summary and recommendation in the bug using the following template.

https://wiki.mozilla.org/CA:Tentative_approval_template

Then a representative of Mozilla may approve the request by noting approval in the bug, after which, the request will move into the inclusion phase as described below.

Inclusion

For root CA certificates approved for inclusion, the Mozilla representative will create a new Bugzilla bug with the information defined in the Inclusion Template.

The new bug number will be noted in a comment in the original bug, and the original bug will be marked as being blocked by the new bug. Please make sure that you are on the CC list of the new bug, so that you can quickly respond to questions that arise during build and test.

For root CA certificates approved for EV, the Mozilla representative will create another bug for the necessary changes to be made to the Mozilla Personal Security Manager (PSM):

  • Summary: Enable [your CA name] for EV
  • Description: Per [original bug #] the request from (CA) to enable its (root name) root certificate for EV use has been approved. Please make the corresponding changes to PSM. The relevant information is as follows: Name, Sha-1 fingerprint, EV Policy OID, test website URL.

It is highly recommended that you make sure you are on the CC list for the new bug(s). The more actively you monitor the new bug(s) and provide requested information, the faster the request can be addressed.

Root inclusion and change requests are usually grouped and done as a batch about every 3 months. At some point within about 3 months of the NSS bug being created, a test build will be provided and the NSS bug will be updated to request that the CA test it. If you are cc'd on the bug, you will get notification via email when that happens.

Here are the steps involved in updating Firefox to include a new root certificate.

  1. The Mozilla representative who shepherded the request through the discussion and approval process creates the NSS bug as described above.
  2. A representative of the CA confirms that all the data in the NSS bug is correct, and that the correct certificate(s) have been attached.
  3. A different Mozilla representative creates a patch with the new certificate(s), and provides a special test version of Firefox.
  4. A representative of the CA uses the test version of Firefox to test that the certificate(s) have been correctly imported and that websites work correctly.
  5. The Mozilla representative who created the patch requests that another Mozilla representative review the patch. This may result in further updates to the patch, until a final patch is agreed on.
  6. The Mozilla representative who created the patch adds (commits) the patch to NSS, then closes the NSS bug as fixed.
  7. The Mozilla representative who created the patch coordinates with the people who test NSS to test the patch as part of an upcoming release of NSS.
  8. The test team completes testing and approves the release of a new version of NSS.
  9. Firefox product drivers decide when to pick up the new release of NSS, and in which versions of Firefox to included the updated version of NSS. This will be in a future version of Firefox, and sometimes a version of NSS will also be released as a security update to previous versions of Firefox.

This work is distributed across many different people, and many different decision factors are considered in determining which version of Firefox will pick up a new version of NSS. This process cannot be expedited for any CA. The only time this process will be expedited is when there is a serious Security Concern.

After the root inclusion or change is confirmed to be included in a release of Firefox, the root information will be moved from the Pending list to the Included list.

Testing Inclusion

Here are the steps that a representative of the CA should take when asked to the test that the certificate has been correctly imported and that websites work correctly.

  1. 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).
  2. Restore the default certificate settings as described here: https://wiki.mozilla.org/CA:UserCertDB#How_To_Restore_Default_Root_Certificate_Settings
    • 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

Frequently Asked Questions

Enable Additional Trust Bits for an included root

How can a CA enable additional trust bits for their root that is already included in Mozilla?

  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.
  4. File a bug by clicking on the "Create a new bug report" link in Section 1.2 above.
    • 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 Verification, Public Discussion, and Inclusion phases as described above.

Enable EV for an included root

How can a CA enable EV for their root that is already included in Mozilla?

  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 that are posted on the CA/Browser Forum website.
  2. Also see the Recommended Practices and Potentially Problematic Practices.
  3. Complete an EV audit that meets the requirements stated in Mozilla's CA Certificate Inclusion Policy.
  4. File a bug by clicking on the "Create a new bug report" link in Section 1.2 above.
    • 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 or ETSI TS 102 042 ("EVCP" and "EVCP+") audit statement.
    • Attach a screenshot to the bug showing successful completion of EV testing, https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version.
  5. The request will go through the Information Verification, Public Discussion, and Inclusion phases as described above.

Include a Renewed root

How can a CA apply for inclusion of new root that is a renewal or rollover of a root that is already included in Mozilla?

  1. Update the CP/CPS to reflect the policies for the new root, 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 and the new root.
  4. File a bug by clicking on the "Create a new bug report" link in Section 1.2 above.
    • Change the bug summary to "Add Renewed [your CA's name] root certificate".
    • 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 Verification, Public Discussion, and Inclusion phases as described above.

Root certificates with the same subject and different keys

The standards allow for two different CA certs with the same subject and with overlapping validities to have different keys (used for key rollover). The trick is if you pick the wrong CA cert when you are validating your chain, you will fail the signature validation. Because of this, CA's will often put two extensions in their certificates: one called the "Subject Key ID Extension", which is placed in the child, and the other is the "Certificate Authority Key Identifier", placed in the parent. These values are a random value that is unique for each key the CA uses. The child's Subject KeyID must match the parent's Certificate Authority Key Identifier if the latter exists. The standard allows for a way to generate a Auth Key ID from a hash, so it's not strictly necessary to include the Auth Key ID in the parent certificate, but it's good practice. NSS will use Subject Key ID to filter out certificates without the matching Auth Key ID automatically. If the CA issues it's certificates with these extensions, there isn't a problem with 2 certs with the same subject but different keys (or even key length).

Root certificates with the same subject and same key

There are cases where CAs have multiple certs with the same subject and same key (for root certificates subject == issuer). The basic times this occurs are:

  1. A CA spins up a new root with an old key because the old root is about to expire or uses an old certificate signature algorithm. NSS sorts certs by validity periods so that the new cert is chosen. bug 515462#c27 has an example of an intermediate cert that contains the issuer name and serial number, but not the issuer's key id, so when the new root cert was added to NSS, the intermediate cert could be trusted by the new cert.
  2. A CA initially spins up with an intermediate signed by a competitor while they get their paperwork for inclusion in all browsers. The CA then spins up it's own root cert.
  3. The CA participates in a bridge system. In this case the user trusts one CA. Each CA signs an intermediate which authenticates the Bridge CA (with whatever appropriate constraints the CA puts on the bridge). The Bridge CA signs an intermediate which authenticates the CA.

NOTE: For cases 1 & 2 above if NSS does not trust the newer cert, the existence of that cert in the wild could challenge certificate validation in the old NSS code, at least until bug 764393 was fixed.

Root certificates with the same subject and serial number

Do not create root certificates with the same subject and serial number. For root certificates subject == issuer.

NSS does not support certificates with the same issuer and serial number.

  • bug 312732#c19 - NSS has been designed internally to rely heavily on the issuer+serial uniqueness assumption
  • bug 435013#c43 - serial number uniqueness is used for revocation checking and for mitigate collision attacks against certs signed with weak hash functions.
  • bug 727204 - NSS 3.13.x is capable of blocking certificates by issuer DN and serial number by adding an appropriate trust record to NSS' builtin module

Changing Verified By Information

A CA with a root certificate currently included in Mozilla products should contact Mozilla directly, via certificates@mozilla.org, to inform Mozilla when an acquisition has taken place relating to the ownership and/or operations of the root certificate.

In regards to re-branding...

  • The text that is displayed within the blue or green bar in the address field of the Firefox browser is obtained directly from the end-entity SSL certificate.
  • The "Verified by" popup information is also obtained directly from the end-entity SSL certificate (Issuer Organization or Issuer Common Name).

Therefore a CA may change the information that is displayed in the "Verified by" popup, by creating a new intermediate issuing certificate with the desired information in the Subject Organization or Common Name.