Confirm, administrator
5,526
edits
Changes
Moved from CA:FAQ to CA/FAQ
When distributing binary and source code versions of Firefox, Thunderbird, and other Mozilla-related software products, Mozilla may include with such software a default set of X.509v3 certificates for various Certification Authorities (CAs). The certificates included by default have their "trust bits" set for various purposes, so that the software in question can use the CA certificates to verify certificates for SSL servers, S/MIME email users, and digitally-signed code objects without having to ask users for further permission or information.
The purpose of this wiki page is to provide general background information regarding how Mozilla software products use certificates, how it is determined which CA certificates are included by default, and how you can influence decisions regarding Mozilla's CA Certificates Module and Policy.
=== What are certificates? ===
Certificates are used in the context of "public key" cryptography. More specifically, certificates are digitally signed data items combining a public key used for some purpose (e.g., enabling a web server to accept SSL connections) with information about the entity associated with the public key. Certificates are used in at least three functions within Mozilla and related software:
* when a user uses the software to connect to an SSL-enabled web server or other SSL-enabled servers, (e.g., an IMAP mail server)
* when a user uses the software to read digitally signed email from another user
* when a user uses the software to download and execute digitally signed executable code (e.g., a digitally-signed Java applet)
In public key cryptography the communicating entities (e.g., web servers or user email programs) each have a unique pair of cryptographic keys, a "private" key that is kept secret and a "public" key that is made known to others. In the various cryptography-based functions in Mozilla mentioned above public keys are not used in their "raw" form but rather are encapsulated in "certificates". (These are often referred to as "X.509 v3 certificates", from the name of the technical standard defining the certificates' format.)
As noted above, a certificate is a digitally signed bundle of data that includes both the public key for a given entity and various pieces of information about that entity; for example, the certificate for a secure web server includes the domain name of the server, a certificate used for secure email includes the email address of the sending user, and the certificate for a signed Java applet includes the name of the organization or individual who developed and/or distributed the applet.
Digitally signing a certificate (or any other data) is done using some entity's private key. More specifically, certificate data are signed by taking the bit string representing the data and putting it through a specially-designed "hashing" operation that generates a small fixed-length bit string, and then encrypting that new bit string (the "hash") using some entity's private key to generate the "signature". Hash functions are mathematically designed to ensure that different bit strings will generate different hash values, and public/private key pairs and algorithms are designed to ensure that data encrypted by a private key can be easily decrypted only by the corresponding public key. (In both cases these guarantees are not absolute, but are as good as skilled cryptographers can make them.)
Someone receiving a copy of the data and its signature can verify the data and signature by decrypting the signature using the entity's public key to recover the original hash value, separately hashing the data to generate a new hash value, and then comparing the original hash value and the new hash value. If the recovered hash value and the newly-generated hash value match then the receiver can be reasonably sure that the data received are the same as the data as originally signed, and that the entity whose public key was used to verify the signature is the same entity that did the signing (with the corresponding private key).
=== What are CAs? ===
Briefly, a Certification Authority or CA is an entity that digitally signs other entities' certificates. (A Certification Authority is also sometimes referred to as a Certificate Authority.)
As mentioned previously, a certificate contains an entity's public key, and is digitally signed using some entity's private key. A "self-signed" certificate is one in which the private key used to digitally sign the certificate is the private key corresponding to the public key in the certificate itself; in other words, the entity signing the certificate is the same entity whose public key is in the certificate (hence the term "self-signed").
Verifying the digital signature on a self-signed certificate can then be done using the public key in the certificate itself, as described above. If the signature is valid then we can be reasonably sure that the public key in the certificate has not been corrupted in any way, and that any other data found in the certificate is as originally put there by the entity associated with the certificate and public key.
It is also possible for a certificate to be signed using some other private key belonging to a third party (i.e., an entity other than the one whose certificate it is). In this case verifying the information in the certificate requires having the public key for that third party. The third party's public key can itself be distributed in the form of a certificate, and that certificate can in turn be signed either by the third party itself (as a self-signed certificate) or by some other party entirely.
In the scheme used by Mozilla, certificates for entities such as web servers, email users, or code developers are typically not self-signed but rather are signed by third parties (organizations or individuals) known as "Certification Authorities" or "CAs" for short. (CAs are in turn considered to be part of what is commonly referred to as a Public Key Infrastructure or PKI — although in fact it is possible to have a PKI that does not use CAs.) By signing the data in certificates CAs are assumed to be in some way vouching for the information contained in the certificate data.
For example, a certificate used for a secure web server normally contains the domain name used to connect to the web server, and by signing such a certificate a CA is assumed to be vouching for the fact that the entity operating the web server (the entity that controls the server's private key corresponding to the public key in the certificate) actually controls the domain name associated with the server. Similarly, a certificate used for secure email should contain the email address of the person or organization that controls the corresponding email account, with the CA signing the certificate assumed to have verified that that is the case, and a certificate used for a digitally signed applet (or other executable code) should contain the name of the developer or distributor of the applet (again, assumed to be verified by the CA).
Verifying a typical web server, email user, or developer certificate then requires having the public key for the CA that signed the certificate. The CA's public key is itself distributed in the form of a certificate; this "CA certificate" is in turn digitally signed either by some other CA or by the CA itself (as a self-signed certificate). In the former case the CA is referred to as an "intermediate" CA; in the latter case the CA is referred to as a "root" CA, and its certificate is a "root CA certificate".
In general it is possible to have multiple root CAs; each root CA can then "issue" certificates directly for web servers, email users, developers, etc., by digitally signing the data in those certificates, or can issue certificates to one or more intermediate CAs, which then issue certificates in turn.
Note that in theory CAs are not necessary in order to support cryptography-based functions like secure web browsing, etc., and in fact there are systems like PGP that do not use CAs in the sense defined above. (PGP uses a separate "web of trust" system in which PGP users sign each others' keys.) However the main cryptography-based functions in Mozilla — secure web browsing, secure email, and digitally signed code objects — do assume the use of CAs, including root CAs.
=== Why does Mozilla include a default set of CA certificates? ===
Mozilla as distributed includes various CA certificates by default, in order to reduce the amount of configuration users have to do before they can use Mozilla for these cryptographic-based functions.
As discussed in the answer to the previous question, in order to verify a certificate for a web server, email user, or code developer, Mozilla must have the certificate for the CA that issued (i.e., digitally signed) the certificate being verified. If the CA is an intermediate CA then Mozilla must also have the certificate for the CA that issued the intermediate CA's certificate, in order to verify that certificate as well. This other CA may be a root CA or yet another intermediate CA; in the latter case yet another CA will be involved, and so on.
Mozilla continues verifying certificates until it comes to a point where it needs a root CA certificate, corresponding to the root CA that issued the original web server, etc., certificate or that issued an intermediate CA's certificate. Since root CA certificates are self-signed, Mozilla can verify such a certificate using the public key in the root CA certificate itself, and if that verification completes successfully then the process is done.
In some cases Mozilla can get the CA certificate(s) from the same place and in the same way as it got the original certificate; for example, if a web server presents its own certificates to Mozilla then it could also present the needed CA certificate(s) as well, including the root CA certificate and any intermediate CA certificates. (Such a set of linked certificates is known as a "certificate chain".)
However it is also convenient for Mozilla to keep its own copies of certificates, including root CA certificates in particular. Among other things, Mozilla can mark a given root CA certificate as being valid for verifying certain types of certificates, and as not being valid to verify other types of certificates.
For example, a particular root CA may issue certificates only for web servers, not for email users or code developers; in the Mozilla certificate database this root CA's certificate could be marked as being valid only for verifying web server certificates. If Mozilla receives a email user certificate issued by this root CA (or by an intermediate CA under the root CA) it would then raise an error condition and alert the user; on the other hand web server certificates issued by the root CA (or an intermediate CA under it) would be verified by Mozilla without error and with no need for user intervention.
This process of marking root CA certificates as being valid for verifying certain types of certificates is commonly known as "trusting" the root CA, and the special flags associated with each root CA certificate are known as "trust bits".
If Mozilla or related software did not already have a copy of a given root CA certificate then it would be unable to automatically determine whether certificates issued by that root CA (or subordinate CAs) should be accepted or not, and would have to prompt the user as to what to do. Most users don't know what CAs are or don't possess the necessary information to properly decide what Mozilla should do. To prevent these typical Mozilla users from having to deal with this issue, Mozilla and related software includes a pre-loaded set of default root CA certificates, with the trust bits set appropriately.
These pre-loaded root CA certificates are distributed with Mozilla and related software in the form of a shared library installed on users' systems along with the rest of the software executable code. They can therefore be updated when new versions of the software are released.
The pre-loaded CA certificates are included in the following files:
* Windows: libnssckbi.dll
* Unix, Linux, and other *nix variants: libnssckbi.so
* Mac OS X: Contents/MacOS/libnssckbi.dynlib
The pathnames above are for Firefox, and are relative to the directory in which the Firefox software is installed; the full pathnames depend on the operating system and the exact software in question.
=== What is the Mozilla CA Certificates Module? ===
Mozilla operates under a [http://www.mozilla.org/hacking/module-ownership.html module ownership governance system]. A '''module''' is a discrete unit of code or activity. An '''owner''' is the person in charge of a module or sub-module. A '''peer''' is a person whom the owner has appointed to help them.
Mozilla's [[Module_Owners_Activities_Modules#CA_Certificates_Module| CA Certificates Module]] is used by all Mozilla software that includes root certificates. It involves evaluation of root inclusion requests, evaluation of requests to change default settings of trust bits for root certificates, inclusion of root certificates, modification of trust bits of root certificates, publication of links to current [https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html documentation and audit statements] for included root certificates, and removal of root certificates. The software for including root certificates and setting trust bits is in the [[NSS | Network Security Services (NSS)]] library.
[https://developer.mozilla.org/en-US/docs/Highlevel_Overview_of_NSS About NSS]
=== What is the Mozilla CA Certificate Policy? ===
The [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy] is the official Mozilla policy for CA certificates that are distributed with Mozilla software products. This policy consists of three sections:
# [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Mozilla CA Certificate Inclusion Policy:] This section describes the obligations of Certification Authorities applying for inclusion of their root certificates in Mozilla Products. This includes considerations that are taken into account such as the CA's publicly available documentation about their policies, and audits of the CA's operations in support of the documented policies.
# [http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html Mozilla CA Certificate Maintenance Policy:] This section describes the obligations of Certification Authorities for maintaining confidence in their root certificates that are included in Mozilla Products. This includes regular auditing of the CA's policies and practices; conforming to current CA industry standards and recommended best practices; and making changes to included root certificates.
# [http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html Mozilla CA Certificate Enforcement Policy:] This section describes the steps that Mozilla may take in order to enforce this policy. This includes evaluation of security concerns, and removing or disabling a root certificate.
The [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy] applies only to software products distributed by Mozilla, including the Mozilla Foundation and its subsidiaries. Other entities distributing such software are free to adopt their own policies. In particular, under the terms of the relevant Mozilla license(s) distributors of such software are permitted to add or delete CA certificates in the versions that they distribute, and are also permitted to modify the values of the "trust bits" on CA certificates in the default CA certificate set. As with other software modifications, by making such changes a distributor may affect its ability to use Mozilla trademarks in connection with its versions of the software; see the Mozilla trademark policy for more information.
=== How do I get my website's certificate to be trusted by Firefox? ===
If your certificates will be used to verify a small number of domains (e.g. *.yourcompany.com) but you want others outside of your organization to be able to browse to your website using https without having to manually import a root certificate, then you can get an [https://en.wikipedia.org/wiki/Public_key_certificate SSL certificate] from one of the CAs who already have a root certificate [[CA:IncludedCAs|included in Firefox]], or get an [https://en.wikipedia.org/wiki/Intermediate_certificate_authorities intermediate certificate] cross-signed by one of the CAs who already have a root certificate [[CA:IncludedCAs|included in Firefox]].
Reference: https://developer.mozilla.org/docs/Mozilla/Security/x509_Certificates#CAs_included_in_Firefox
=== Who decides which CA certificates to include in Mozilla products? ===
For a CA's root certificate to be considered for inclusion in Mozilla products, the CA makes a formal request by filing a bug in [[CA:How_to_apply | Mozilla's Bugzilla system]]. Then the owners or peers of Mozilla's [[Module_Owners_Activities_Modules#CA_Certificates_Module| CA Certificates Module]] evaluate the information provided by the CA and conduct a public discussion in the mozilla.dev.security.policy forum regarding the request. After considering the information that the CA has presented and the recommendations of the Mozilla community, the module owners or peers determine if the root certificate should be included in Mozilla software products and which trust bits should be set on them.
=== How does a CA certificate get included in Mozilla products? ===
For a high level description of the root inclusion process see: https://wiki.mozilla.org/CA
For details about how a CA may apply for root inclusion see: https://wiki.mozilla.org/CA:How_to_apply
The main phases involved in including a root certificate in Mozilla products are:
# The CA files a bug to request inclusion of their root certificate.
# A representative of Mozilla verifies the information provided by the CA.
# A representative of Mozilla conducts a public discussion of the request in the mozilla.dev.security.policy discussion forum.
# A Mozilla CA Certificates Module owner or peer posts their recommendation for approval, denial, or further work in the bug.
# If appropriate, the module owner or peer approves the request, then files a bug against NSS for the actual changes.
# A developer modifies the NSS code to include the root certificate, and the CA tests the change.
# Future releases of Mozilla products include the new version of NSS.
=== What if I don't trust a particular CA? ===
If you don't trust a particular CA whose root certificate is included by default in Mozilla products, then there are two ways to disable the certificate.
# [[CA:UserCertDB#Changing_Root_Certificate_Trust_Bit_Settings | Turn off the trust bits for that root certificate.]]
# [[CA:UserCertDB#Deleting_a_Root_Certificate | Delete the root certificate.]]
#* Deleting a root certificate that is in the default root store is equivalent to turning off all of the trust bits for that root. Therefore, even though the root certificate will re-appear in the Certificate Manager, it will be treated as though you changed the trust bits of that root certificate to turn them all off.
'''Important:''' This change will have a permanent affect, such that the trust bits for the root certificate can only be changed again by you. This change will not be affected by upgrading to newer versions of Mozilla software. It is strongly recommended that you note which root certificate you modify, so that you can turn the trust bits back on if the change negatively impacts your browsing experience.
=== How can I impact Mozilla's default set of CA certificates? ===
You may influence the decisions about root inclusion requests by contributing to the discussions in the mozilla.dev.security.policy forum.
If a CA you care about is in the [[CA:Schedule#Queue_for_Public_Discussion | queue for public discussion]], the best way to move it towards inclusion is to quickly and diligently review and contribute to discussions of the applications of CAs ahead of it.
* [[CA:Schedule#Queue_for_Public_Discussion | Queue for public discussion]]
* [[CA:How_to_apply#Public_discussion | Reviewing applications and contributing to discussions]]
=== Why does SSL handshake fail due to missing intermediate certificate? ===
This type of error indicates that the web server is incorrectly configured. The web server itself has to send the intermediate certificate along with their own SSL cert to complete the certificate chain. Only root certificates or trust anchors are included in the Mozilla root store.
=== Can I use Mozilla's set of CA certificates? ===
The decisions Mozilla makes with regards to the inclusion or exclusion of CA certificates in its root store are directly tied to the capabilities and behaviours of the software Mozilla distributes. Sometimes, a security change is made wholly or partly in the software instead of the root store. Further, Mozilla does not promise to take into account the needs of other users of its root store when making such decisions.
Therefore, anyone considering bundling Mozilla's root store with other software needs to be aware of the issues surrounding providing a root store, and committed to making sure that they maintain security for their users by carefully observing Mozilla's actions and taking appropriate steps of their own. On a best-efforts basis, Mozilla maintains [[CA:Root_Store_Trust_Mods|a list]] of the additional things users of our store might need to consider.
For additional context see the [https://groups.google.com/d/msg/mozilla.dev.security.policy/FYIBEF_AVMI/2KYQrWirsiQJ discussion in mozilla.dev.security policy].
'''Important''': Consumers of this root store must consider the trust bit settings for each included root certificate.
* [https://www.imperialviolet.org/2012/01/30/mozillaroots.html Why Trust Bits Matter]
* [https://github.com/agl/extract-nss-root-certs Extracting roots and their trust bits]
=== How do I import a root cert into NSS on our organization's internal servers? ===
In some organizations administrators need to configure additional trusted CAs or override the trust settings of CAs on a system wide level, as required by local system environments or corporate deployments. For example, some organizations have their own in-house CA, and need to automate importing their root certificate(s) into NSS on their internal servers.
Here are some resources about this.
* Adding Certificates for Firefox
** [[CA:AddRootToFirefox | Add any root certificate]]
** [https://addons.mozilla.org/en-us/firefox/addon/cacert-root-certificate/ Add CACert root only]
* Adding Certificates to NSS for other applications
** [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/tools/NSS_Tools_certutil certutil] -- a command-line utility that can be used to list, generate, modify, or delete certificates in the NSS root store.
*** [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/tools#Tools_Information NSS Tools]
*** [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Sources_Building_Testing Getting and building NSS]
** For systems with Fedora and RHEL (6.5 and newer) see the manual page for update-ca-trust (man update-ca-trust)
** For systems with Ubuntu/Debian see the manual page for update-ca-certificates
* [https://www.mozilla.org/en-US/about/forums/#dev-tech-crypto Discussion forum] where you can ask questions and get answers from others who have done this
The purpose of this wiki page is to provide general background information regarding how Mozilla software products use certificates, how it is determined which CA certificates are included by default, and how you can influence decisions regarding Mozilla's CA Certificates Module and Policy.
=== What are certificates? ===
Certificates are used in the context of "public key" cryptography. More specifically, certificates are digitally signed data items combining a public key used for some purpose (e.g., enabling a web server to accept SSL connections) with information about the entity associated with the public key. Certificates are used in at least three functions within Mozilla and related software:
* when a user uses the software to connect to an SSL-enabled web server or other SSL-enabled servers, (e.g., an IMAP mail server)
* when a user uses the software to read digitally signed email from another user
* when a user uses the software to download and execute digitally signed executable code (e.g., a digitally-signed Java applet)
In public key cryptography the communicating entities (e.g., web servers or user email programs) each have a unique pair of cryptographic keys, a "private" key that is kept secret and a "public" key that is made known to others. In the various cryptography-based functions in Mozilla mentioned above public keys are not used in their "raw" form but rather are encapsulated in "certificates". (These are often referred to as "X.509 v3 certificates", from the name of the technical standard defining the certificates' format.)
As noted above, a certificate is a digitally signed bundle of data that includes both the public key for a given entity and various pieces of information about that entity; for example, the certificate for a secure web server includes the domain name of the server, a certificate used for secure email includes the email address of the sending user, and the certificate for a signed Java applet includes the name of the organization or individual who developed and/or distributed the applet.
Digitally signing a certificate (or any other data) is done using some entity's private key. More specifically, certificate data are signed by taking the bit string representing the data and putting it through a specially-designed "hashing" operation that generates a small fixed-length bit string, and then encrypting that new bit string (the "hash") using some entity's private key to generate the "signature". Hash functions are mathematically designed to ensure that different bit strings will generate different hash values, and public/private key pairs and algorithms are designed to ensure that data encrypted by a private key can be easily decrypted only by the corresponding public key. (In both cases these guarantees are not absolute, but are as good as skilled cryptographers can make them.)
Someone receiving a copy of the data and its signature can verify the data and signature by decrypting the signature using the entity's public key to recover the original hash value, separately hashing the data to generate a new hash value, and then comparing the original hash value and the new hash value. If the recovered hash value and the newly-generated hash value match then the receiver can be reasonably sure that the data received are the same as the data as originally signed, and that the entity whose public key was used to verify the signature is the same entity that did the signing (with the corresponding private key).
=== What are CAs? ===
Briefly, a Certification Authority or CA is an entity that digitally signs other entities' certificates. (A Certification Authority is also sometimes referred to as a Certificate Authority.)
As mentioned previously, a certificate contains an entity's public key, and is digitally signed using some entity's private key. A "self-signed" certificate is one in which the private key used to digitally sign the certificate is the private key corresponding to the public key in the certificate itself; in other words, the entity signing the certificate is the same entity whose public key is in the certificate (hence the term "self-signed").
Verifying the digital signature on a self-signed certificate can then be done using the public key in the certificate itself, as described above. If the signature is valid then we can be reasonably sure that the public key in the certificate has not been corrupted in any way, and that any other data found in the certificate is as originally put there by the entity associated with the certificate and public key.
It is also possible for a certificate to be signed using some other private key belonging to a third party (i.e., an entity other than the one whose certificate it is). In this case verifying the information in the certificate requires having the public key for that third party. The third party's public key can itself be distributed in the form of a certificate, and that certificate can in turn be signed either by the third party itself (as a self-signed certificate) or by some other party entirely.
In the scheme used by Mozilla, certificates for entities such as web servers, email users, or code developers are typically not self-signed but rather are signed by third parties (organizations or individuals) known as "Certification Authorities" or "CAs" for short. (CAs are in turn considered to be part of what is commonly referred to as a Public Key Infrastructure or PKI — although in fact it is possible to have a PKI that does not use CAs.) By signing the data in certificates CAs are assumed to be in some way vouching for the information contained in the certificate data.
For example, a certificate used for a secure web server normally contains the domain name used to connect to the web server, and by signing such a certificate a CA is assumed to be vouching for the fact that the entity operating the web server (the entity that controls the server's private key corresponding to the public key in the certificate) actually controls the domain name associated with the server. Similarly, a certificate used for secure email should contain the email address of the person or organization that controls the corresponding email account, with the CA signing the certificate assumed to have verified that that is the case, and a certificate used for a digitally signed applet (or other executable code) should contain the name of the developer or distributor of the applet (again, assumed to be verified by the CA).
Verifying a typical web server, email user, or developer certificate then requires having the public key for the CA that signed the certificate. The CA's public key is itself distributed in the form of a certificate; this "CA certificate" is in turn digitally signed either by some other CA or by the CA itself (as a self-signed certificate). In the former case the CA is referred to as an "intermediate" CA; in the latter case the CA is referred to as a "root" CA, and its certificate is a "root CA certificate".
In general it is possible to have multiple root CAs; each root CA can then "issue" certificates directly for web servers, email users, developers, etc., by digitally signing the data in those certificates, or can issue certificates to one or more intermediate CAs, which then issue certificates in turn.
Note that in theory CAs are not necessary in order to support cryptography-based functions like secure web browsing, etc., and in fact there are systems like PGP that do not use CAs in the sense defined above. (PGP uses a separate "web of trust" system in which PGP users sign each others' keys.) However the main cryptography-based functions in Mozilla — secure web browsing, secure email, and digitally signed code objects — do assume the use of CAs, including root CAs.
=== Why does Mozilla include a default set of CA certificates? ===
Mozilla as distributed includes various CA certificates by default, in order to reduce the amount of configuration users have to do before they can use Mozilla for these cryptographic-based functions.
As discussed in the answer to the previous question, in order to verify a certificate for a web server, email user, or code developer, Mozilla must have the certificate for the CA that issued (i.e., digitally signed) the certificate being verified. If the CA is an intermediate CA then Mozilla must also have the certificate for the CA that issued the intermediate CA's certificate, in order to verify that certificate as well. This other CA may be a root CA or yet another intermediate CA; in the latter case yet another CA will be involved, and so on.
Mozilla continues verifying certificates until it comes to a point where it needs a root CA certificate, corresponding to the root CA that issued the original web server, etc., certificate or that issued an intermediate CA's certificate. Since root CA certificates are self-signed, Mozilla can verify such a certificate using the public key in the root CA certificate itself, and if that verification completes successfully then the process is done.
In some cases Mozilla can get the CA certificate(s) from the same place and in the same way as it got the original certificate; for example, if a web server presents its own certificates to Mozilla then it could also present the needed CA certificate(s) as well, including the root CA certificate and any intermediate CA certificates. (Such a set of linked certificates is known as a "certificate chain".)
However it is also convenient for Mozilla to keep its own copies of certificates, including root CA certificates in particular. Among other things, Mozilla can mark a given root CA certificate as being valid for verifying certain types of certificates, and as not being valid to verify other types of certificates.
For example, a particular root CA may issue certificates only for web servers, not for email users or code developers; in the Mozilla certificate database this root CA's certificate could be marked as being valid only for verifying web server certificates. If Mozilla receives a email user certificate issued by this root CA (or by an intermediate CA under the root CA) it would then raise an error condition and alert the user; on the other hand web server certificates issued by the root CA (or an intermediate CA under it) would be verified by Mozilla without error and with no need for user intervention.
This process of marking root CA certificates as being valid for verifying certain types of certificates is commonly known as "trusting" the root CA, and the special flags associated with each root CA certificate are known as "trust bits".
If Mozilla or related software did not already have a copy of a given root CA certificate then it would be unable to automatically determine whether certificates issued by that root CA (or subordinate CAs) should be accepted or not, and would have to prompt the user as to what to do. Most users don't know what CAs are or don't possess the necessary information to properly decide what Mozilla should do. To prevent these typical Mozilla users from having to deal with this issue, Mozilla and related software includes a pre-loaded set of default root CA certificates, with the trust bits set appropriately.
These pre-loaded root CA certificates are distributed with Mozilla and related software in the form of a shared library installed on users' systems along with the rest of the software executable code. They can therefore be updated when new versions of the software are released.
The pre-loaded CA certificates are included in the following files:
* Windows: libnssckbi.dll
* Unix, Linux, and other *nix variants: libnssckbi.so
* Mac OS X: Contents/MacOS/libnssckbi.dynlib
The pathnames above are for Firefox, and are relative to the directory in which the Firefox software is installed; the full pathnames depend on the operating system and the exact software in question.
=== What is the Mozilla CA Certificates Module? ===
Mozilla operates under a [http://www.mozilla.org/hacking/module-ownership.html module ownership governance system]. A '''module''' is a discrete unit of code or activity. An '''owner''' is the person in charge of a module or sub-module. A '''peer''' is a person whom the owner has appointed to help them.
Mozilla's [[Module_Owners_Activities_Modules#CA_Certificates_Module| CA Certificates Module]] is used by all Mozilla software that includes root certificates. It involves evaluation of root inclusion requests, evaluation of requests to change default settings of trust bits for root certificates, inclusion of root certificates, modification of trust bits of root certificates, publication of links to current [https://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html documentation and audit statements] for included root certificates, and removal of root certificates. The software for including root certificates and setting trust bits is in the [[NSS | Network Security Services (NSS)]] library.
[https://developer.mozilla.org/en-US/docs/Highlevel_Overview_of_NSS About NSS]
=== What is the Mozilla CA Certificate Policy? ===
The [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy] is the official Mozilla policy for CA certificates that are distributed with Mozilla software products. This policy consists of three sections:
# [http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html Mozilla CA Certificate Inclusion Policy:] This section describes the obligations of Certification Authorities applying for inclusion of their root certificates in Mozilla Products. This includes considerations that are taken into account such as the CA's publicly available documentation about their policies, and audits of the CA's operations in support of the documented policies.
# [http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html Mozilla CA Certificate Maintenance Policy:] This section describes the obligations of Certification Authorities for maintaining confidence in their root certificates that are included in Mozilla Products. This includes regular auditing of the CA's policies and practices; conforming to current CA industry standards and recommended best practices; and making changes to included root certificates.
# [http://www.mozilla.org/projects/security/certs/policy/EnforcementPolicy.html Mozilla CA Certificate Enforcement Policy:] This section describes the steps that Mozilla may take in order to enforce this policy. This includes evaluation of security concerns, and removing or disabling a root certificate.
The [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy] applies only to software products distributed by Mozilla, including the Mozilla Foundation and its subsidiaries. Other entities distributing such software are free to adopt their own policies. In particular, under the terms of the relevant Mozilla license(s) distributors of such software are permitted to add or delete CA certificates in the versions that they distribute, and are also permitted to modify the values of the "trust bits" on CA certificates in the default CA certificate set. As with other software modifications, by making such changes a distributor may affect its ability to use Mozilla trademarks in connection with its versions of the software; see the Mozilla trademark policy for more information.
=== How do I get my website's certificate to be trusted by Firefox? ===
If your certificates will be used to verify a small number of domains (e.g. *.yourcompany.com) but you want others outside of your organization to be able to browse to your website using https without having to manually import a root certificate, then you can get an [https://en.wikipedia.org/wiki/Public_key_certificate SSL certificate] from one of the CAs who already have a root certificate [[CA:IncludedCAs|included in Firefox]], or get an [https://en.wikipedia.org/wiki/Intermediate_certificate_authorities intermediate certificate] cross-signed by one of the CAs who already have a root certificate [[CA:IncludedCAs|included in Firefox]].
Reference: https://developer.mozilla.org/docs/Mozilla/Security/x509_Certificates#CAs_included_in_Firefox
=== Who decides which CA certificates to include in Mozilla products? ===
For a CA's root certificate to be considered for inclusion in Mozilla products, the CA makes a formal request by filing a bug in [[CA:How_to_apply | Mozilla's Bugzilla system]]. Then the owners or peers of Mozilla's [[Module_Owners_Activities_Modules#CA_Certificates_Module| CA Certificates Module]] evaluate the information provided by the CA and conduct a public discussion in the mozilla.dev.security.policy forum regarding the request. After considering the information that the CA has presented and the recommendations of the Mozilla community, the module owners or peers determine if the root certificate should be included in Mozilla software products and which trust bits should be set on them.
=== How does a CA certificate get included in Mozilla products? ===
For a high level description of the root inclusion process see: https://wiki.mozilla.org/CA
For details about how a CA may apply for root inclusion see: https://wiki.mozilla.org/CA:How_to_apply
The main phases involved in including a root certificate in Mozilla products are:
# The CA files a bug to request inclusion of their root certificate.
# A representative of Mozilla verifies the information provided by the CA.
# A representative of Mozilla conducts a public discussion of the request in the mozilla.dev.security.policy discussion forum.
# A Mozilla CA Certificates Module owner or peer posts their recommendation for approval, denial, or further work in the bug.
# If appropriate, the module owner or peer approves the request, then files a bug against NSS for the actual changes.
# A developer modifies the NSS code to include the root certificate, and the CA tests the change.
# Future releases of Mozilla products include the new version of NSS.
=== What if I don't trust a particular CA? ===
If you don't trust a particular CA whose root certificate is included by default in Mozilla products, then there are two ways to disable the certificate.
# [[CA:UserCertDB#Changing_Root_Certificate_Trust_Bit_Settings | Turn off the trust bits for that root certificate.]]
# [[CA:UserCertDB#Deleting_a_Root_Certificate | Delete the root certificate.]]
#* Deleting a root certificate that is in the default root store is equivalent to turning off all of the trust bits for that root. Therefore, even though the root certificate will re-appear in the Certificate Manager, it will be treated as though you changed the trust bits of that root certificate to turn them all off.
'''Important:''' This change will have a permanent affect, such that the trust bits for the root certificate can only be changed again by you. This change will not be affected by upgrading to newer versions of Mozilla software. It is strongly recommended that you note which root certificate you modify, so that you can turn the trust bits back on if the change negatively impacts your browsing experience.
=== How can I impact Mozilla's default set of CA certificates? ===
You may influence the decisions about root inclusion requests by contributing to the discussions in the mozilla.dev.security.policy forum.
If a CA you care about is in the [[CA:Schedule#Queue_for_Public_Discussion | queue for public discussion]], the best way to move it towards inclusion is to quickly and diligently review and contribute to discussions of the applications of CAs ahead of it.
* [[CA:Schedule#Queue_for_Public_Discussion | Queue for public discussion]]
* [[CA:How_to_apply#Public_discussion | Reviewing applications and contributing to discussions]]
=== Why does SSL handshake fail due to missing intermediate certificate? ===
This type of error indicates that the web server is incorrectly configured. The web server itself has to send the intermediate certificate along with their own SSL cert to complete the certificate chain. Only root certificates or trust anchors are included in the Mozilla root store.
=== Can I use Mozilla's set of CA certificates? ===
The decisions Mozilla makes with regards to the inclusion or exclusion of CA certificates in its root store are directly tied to the capabilities and behaviours of the software Mozilla distributes. Sometimes, a security change is made wholly or partly in the software instead of the root store. Further, Mozilla does not promise to take into account the needs of other users of its root store when making such decisions.
Therefore, anyone considering bundling Mozilla's root store with other software needs to be aware of the issues surrounding providing a root store, and committed to making sure that they maintain security for their users by carefully observing Mozilla's actions and taking appropriate steps of their own. On a best-efforts basis, Mozilla maintains [[CA:Root_Store_Trust_Mods|a list]] of the additional things users of our store might need to consider.
For additional context see the [https://groups.google.com/d/msg/mozilla.dev.security.policy/FYIBEF_AVMI/2KYQrWirsiQJ discussion in mozilla.dev.security policy].
'''Important''': Consumers of this root store must consider the trust bit settings for each included root certificate.
* [https://www.imperialviolet.org/2012/01/30/mozillaroots.html Why Trust Bits Matter]
* [https://github.com/agl/extract-nss-root-certs Extracting roots and their trust bits]
=== How do I import a root cert into NSS on our organization's internal servers? ===
In some organizations administrators need to configure additional trusted CAs or override the trust settings of CAs on a system wide level, as required by local system environments or corporate deployments. For example, some organizations have their own in-house CA, and need to automate importing their root certificate(s) into NSS on their internal servers.
Here are some resources about this.
* Adding Certificates for Firefox
** [[CA:AddRootToFirefox | Add any root certificate]]
** [https://addons.mozilla.org/en-us/firefox/addon/cacert-root-certificate/ Add CACert root only]
* Adding Certificates to NSS for other applications
** [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/tools/NSS_Tools_certutil certutil] -- a command-line utility that can be used to list, generate, modify, or delete certificates in the NSS root store.
*** [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/tools#Tools_Information NSS Tools]
*** [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Sources_Building_Testing Getting and building NSS]
** For systems with Fedora and RHEL (6.5 and newer) see the manual page for update-ca-trust (man update-ca-trust)
** For systems with Ubuntu/Debian see the manual page for update-ca-certificates
* [https://www.mozilla.org/en-US/about/forums/#dev-tech-crypto Discussion forum] where you can ask questions and get answers from others who have done this
