|
|
| Line 1: |
Line 1: |
| This page provides information about the steps a Mozilla representative will take during evaluation of a CA's root inclusion or change request. | | This page provides information about the steps a Mozilla representative will take during evaluation of a CA's root inclusion or change request. |
|
| |
|
| == Information Verification ==
| | = 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|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. | | 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|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. |
| Line 52: |
Line 52: |
| 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 [http://www.mozilla.org/projects/security/certs/pending/ pending CA request list] will be updated to “Information confirmed complete”. The request will be prioritized and added to the [[CA:Schedule|Queue for Public Discussion]]. The bug will be updated when the request enters into the first public discussion. | | 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 [http://www.mozilla.org/projects/security/certs/pending/ pending CA request list] will be updated to “Information confirmed complete”. The request will be prioritized and added to the [[CA:Schedule|Queue for Public Discussion]]. The bug will be updated when the request enters into the first public discussion. |
|
| |
|
| === 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. | | 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. |
| Line 105: |
Line 105: |
| 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). | | 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 ====
| | == Phase 1 of public discussion == |
|
| |
|
| To begin this phase, a representative of Mozilla will create a new discussion thread in the [http://groups.google.com/group/mozilla.dev.security.policy mozilla.dev.security.policy] newsgroup and will post information to the associated bug that the public discussion has begun. | | To begin this phase, a representative of Mozilla will create a new discussion thread in the [http://groups.google.com/group/mozilla.dev.security.policy mozilla.dev.security.policy] newsgroup and will post information to the associated bug that the public discussion has begun. |
| Line 128: |
Line 128: |
| Otherwise the Mozilla representative will list the action items that must be completed before the second phase of public discussion can begin. | | 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 ====
| | == 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. | | 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 ====
| | == 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 [http://groups.google.com/group/mozilla.dev.security.policy mozilla.dev.security.policy] newsgroup and will post information to the associated bug that the public discussion has begun. | | 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 [http://groups.google.com/group/mozilla.dev.security.policy mozilla.dev.security.policy] newsgroup and will post information to the associated bug that the public discussion has begun. |
| Line 144: |
Line 144: |
| 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. | | 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 === | | = NSS and PSM Bug Creation = |
|
| |
|
| For root CA certificates approved for inclusion, the Mozilla representative will create a new Bugzilla bug with the information defined in the [https://wiki.mozilla.org/CA:Inclusion_template Inclusion Template.] | | For root CA certificates approved for inclusion, the Mozilla representative will create a new Bugzilla bug with the information defined in the [https://wiki.mozilla.org/CA:Inclusion_template Inclusion Template.] |
| Line 172: |
Line 172: |
|
| |
|
| After the root inclusion or change is confirmed to be included in a release of Firefox, the root information will be moved from the [http://www.mozilla.org/projects/security/certs/pending/ Pending list] to the [http://www.mozilla.org/projects/security/certs/included/ Included list]. | | After the root inclusion or change is confirmed to be included in a release of Firefox, the root information will be moved from the [http://www.mozilla.org/projects/security/certs/pending/ Pending list] to the [http://www.mozilla.org/projects/security/certs/included/ Included list]. |
|
| |
| ==== Testing Inclusion ====
| |
| 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: [http://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles Profile Manager] and [http://kb.mozillazine.org/Creating_a_new_Firefox_profile_on_Windows 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 [https://it.uoregon.edu/fix-security-settings 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.
| |
| # 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.
| |
|
| |
| === After Inclusion ===
| |
| CAs must follow [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ Mozilla's CA Certificate Maintenance Policy] the entire time they have a root certificate [[CA:IncludedCAs|included in Mozilla’s CA Certificate Program]].
| |
|
| |
| CAs are required to:
| |
| * Annually provide public-facing statement(s) of attestation of their conformance to the stated verification requirements. ([https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ section 4])
| |
| * 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. ([https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ section 5])
| |
| * Ensure that Mozilla has their current contact information. ([https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ section 6])
| |
|
| |
| Additionally, CAs must maintain their data in the [[CA:SalesforceCommunity|CA Community in Salesforce]] 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 as described in section 9 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy].
| |
| * [[CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates|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 as described in section 9 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy].
| |
|
| |
| [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ Mozilla's CA Certificate Enforcement Policy] outlines action that Mozilla will take when these requirements are not met by CAs with included root certificates.
| |
|
| |
| == 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?
| |
|
| |
| # Update the CP/CPS to reflect the policies for the additional trust bits, and make sure that the additions to the CP/CPS follow [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy], especially section 7.
| |
| # Also see the [[CA:Recommended_Practices|Recommended Practices]] and [[CA:Problematic_Practices|Potentially Problematic Practices]], and in particular:
| |
| #* https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Domain_Name_Ownership
| |
| #* https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Email_Address_Control
| |
| #* https://wiki.mozilla.org/CA:Recommended_Practices#Verifying_Identity_of_Code_Signing_Certificate_Subscriber
| |
| #* Note that whenever a root is changed, the Mozilla representative has to fully review all of the related information, not just the documentation for the trust bits being enabled, but also for the already enabled trust bits and EV treatment.
| |
| # Have the annual audit cover the updated CP/CPS.
| |
| #* Make sure that the audit meets the requirements stated in [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy] sections 11 through 14.
| |
| # File a bug by clicking on the "Create a new bug report" link in [[CA:How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request|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.
| |
| # The request will go through the [[ CA:How_to_apply#Information_Verification|Information Verification]], [[CA:How_to_apply#Public_discussion|Public Discussion]], and [[CA:How_to_apply#Inclusion|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?
| |
|
| |
| # Update the CP/CPS to reflect the EV policies, and make sure that the additions to the CP/CPS follow the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy] as well as the EV SSL Certificate Guidelines that are posted on the CA/Browser Forum website.
| |
| # Also see the [[CA:Recommended_Practices|Recommended Practices]] and [[CA:Problematic_Practices|Potentially Problematic Practices]].
| |
| # Complete an EV audit that meets the requirements stated in [http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy.]
| |
| # File a bug by clicking on the "Create a new bug report" link in [[CA:How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request|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.
| |
| # The request will go through the [[ CA:How_to_apply#Information_Verification|Information Verification]], [[CA:How_to_apply#Public_discussion|Public Discussion]], and [[CA:How_to_apply#Inclusion|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?
| |
|
| |
| # Update the CP/CPS to reflect the policies for the new root, and make sure that the additions to the CP/CPS follow [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy], especially section 7.
| |
| # Also see the [[CA:Recommended_Practices|Recommended Practices]] and [[CA:Problematic_Practices|Potentially Problematic Practices]].
| |
| # Have the annual audit cover the updated CP/CPS and the new root.
| |
| #* Make sure that the audits meet the requirements stated in sections 11 through 14 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy.]
| |
| # File a bug by clicking on the "Create a new bug report" link in [[CA:How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request|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.
| |
| # The request will go through the [[ CA:How_to_apply#Information_Verification|Information Verification]], [[CA:How_to_apply#Public_discussion|Public Discussion]], and [[CA:How_to_apply#Inclusion|Inclusion]] phases as described above.
| |
|
| |
| ==== Root certificates with the same subject and different keys ====
| |
|
| |
| The standards allow for two CA certificates to have the same subject names but different subject public keys. Please try to avoid this, because it often leads to confusion and compatibility issues. When verifying an end-entity certificate chaining up to a root certificate with the same subject name as another root certificate, if Firefox is aware of the existence of both root certificates, it will try all possible orderings of (subject, issuer) pairs until it finds the right one. If there are many certificates all with the same subject and issuer names, the number of orderings grows exponentially, so it can take a long time to evaluate the certificate chains. Therefore, it is better to avoid these kinds of situations.
| |
|
| |
| Note that for root certificates, Firefox ignores the authority key identifier and subject key identifier extensions.
| |
|
| |
| ==== 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:
| |
| # 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.
| |
| # 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.
| |
| # 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.
| |
| <p>
| |
| NSS '''does not''' support certificates with the same issuer and serial number.
| |
| </p>
| |
| * {{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 [[CA:RootTransferPolicy|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.
| |