Confirm, administrator
5,526
edits
Changes
Created page with 'This page describes how to override the default root certificate settings in Mozilla products, including Firefox and Thunderbird. See the [[CA:Root_Change_Process|Root Change Pr…'
This page describes how to override the default root certificate settings in Mozilla products, including Firefox and Thunderbird.
See the [[CA:Root_Change_Process|Root Change Process]] if you are looking for instructions for changing default root certificate settings in Mozilla products.
When distributing binary and source code versions of Firefox, Thunderbird, and other Mozilla-related software products the Mozilla Foundation and its wholly-owned subsidiary the Mozilla Corporation 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.
CAs apply to have their root certificates included by default in Mozilla products by following the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy] and applying for inclusion as per [[CA:How_to_apply|CA:How_to_apply]].
Users of Mozilla products may override the default root certificate settings by either deleting the root certificate or by changing a roots trust bit settings. The sections below describe how to make these changes, and how the software responds to such changes.
Important: If you change the trust bit of a root certificate, that change will be permanent (can only be changed again by you) and will not be affected by upgrading to newer versions of the software. On the other hand, if you delete a root certificate and if that root certificate is in the default root store, then the root certificate will be included again the next time you upgrade to a newer version of the software.
== Changing Root Certificate Trust Bit Settings ==
Firefox On Windows:
Thunderbird On Windows:
Firefox On Mac:
Thunderbird On Mac:
Important: This change will be permanent, such that it can only be changed again by you. This change will not be affected by upgrading to newer versions of Mozilla software.
== Deleting a Root Certificates ==
Firefox On Windows:
Thunderbird On Windows:
Firefox On Mac:
Thunderbird On Mac:
Important: This change may be overridden when you upgrade to the next version of the Mozilla software. If the deleted root certificate is still in Mozilla's default root store, then the root certificate will be included again the next time you upgrade to a newer version of the software.
== How Mozilla Products Respond to User Changes of Root Certificates ==
The following explains how Mozilla products behave when users change or delete root certificates.
For simplicity, I will assume the basic and most common configuration, in
which you have only the software distributed by Mozilla and do not have any
additional PKCS#11 modules (with or without any additional hardware)
installed that may be capable of storing additional certificates. The
model with them is slightly more complicated than the one I'm about to
present, but only slightly.
NSS is capable of accessing certificates that have been stored in a number
of places, all accessible through the PKCS#11 API. The two places of
greatest interest are
#1) Your certificate database, which is kept in a file on disk that you can
alter. It starts out empty. Any root certificates it contains are there
because of actions that you have taken, such as downloading or importing
roots, or editing trust flags. As a rule, an update to your Mozilla
installation of a Mozilla product will not change the contents
of this database. (Rarely, it may change the FORMAT of the database, but
not the content.)
#2) Mozilla's trusted root list, kept in a read-only shared library which
is one of the files that gets updated whenever your product's executable
files get updated.
Both of these stores of certificates may contain certificates and trust
flags.
When NSS goes looking for a stored certificate, or trust flags for a stored
certificate, it first looks in your certificate database. If it finds the
certificate there, it stops. It uses whatever trust flags are there in
that database with that certificate.
If it does NOT find the certificate it wants in that database, it looks in
Mozilla's trusted root list. If it finds the cert there, then it uses the
cert and trust flags it finds there. It does not copy the cert and flags
from the root list into your database. It just uses them where and as they
are.
When you use your product's certificate manager to edit the trust flags on
a certificate, the cert manager first looks for the cert in your database,
and if it's there, then that copy gets edited. If it's not there, then
cert manager looks for a copy in the trusted cert list, and if found,
copies it and its flags into your data base, and then edits it there.
(After all, it cannot edit the copy in Mozilla's list, because that copy
is read-only.) After that, that cert will remain in your database, and
each time that the product goes looking for it, it will find it in your
database, not in the trusted list.
If you delete a cert in your database, one that is also in the trusted
list, it may appear to be completely gone, until you restart your program,
at which point it will reappear, because it never left the trusted root
list. It may reappear in the trusted root list with the trust flags from
that list. That's why we tell people that if they want to get rid of a
root, the thing to do is NOT to delete it, but rather is to take away all
its trust. (The behavior when a cert is deleted has changed a few times
over the years.)
If you edit the trust on a cert in the root list, taking away (say) one of
the 3 trust flags, but leaving the other two, then that cert and the two
trust bits will be in your cert DB. After that, if Mozilla removes that
cert completely from Mozilla's trust list, it will remain in your cert DB
with those two trust flags. Mozilla's changes to the default trust list
never affect your databases. Your databases contain what YOU put there.
They're your baby, your responsibility.
In conclusion, the changes Mozilla makes to Mozilla's read-only list of
trusted root certs affect only those certs that do not also appear in your
cert DB. When you cause copies of any of those certs to appear in your
cert DB, then you have taken control of the trust for those copies, and
changes made by Mozilla thereafter to those certs will not affect you.
See the [[CA:Root_Change_Process|Root Change Process]] if you are looking for instructions for changing default root certificate settings in Mozilla products.
When distributing binary and source code versions of Firefox, Thunderbird, and other Mozilla-related software products the Mozilla Foundation and its wholly-owned subsidiary the Mozilla Corporation 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.
CAs apply to have their root certificates included by default in Mozilla products by following the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy] and applying for inclusion as per [[CA:How_to_apply|CA:How_to_apply]].
Users of Mozilla products may override the default root certificate settings by either deleting the root certificate or by changing a roots trust bit settings. The sections below describe how to make these changes, and how the software responds to such changes.
Important: If you change the trust bit of a root certificate, that change will be permanent (can only be changed again by you) and will not be affected by upgrading to newer versions of the software. On the other hand, if you delete a root certificate and if that root certificate is in the default root store, then the root certificate will be included again the next time you upgrade to a newer version of the software.
== Changing Root Certificate Trust Bit Settings ==
Firefox On Windows:
Thunderbird On Windows:
Firefox On Mac:
Thunderbird On Mac:
Important: This change will be permanent, such that it can only be changed again by you. This change will not be affected by upgrading to newer versions of Mozilla software.
== Deleting a Root Certificates ==
Firefox On Windows:
Thunderbird On Windows:
Firefox On Mac:
Thunderbird On Mac:
Important: This change may be overridden when you upgrade to the next version of the Mozilla software. If the deleted root certificate is still in Mozilla's default root store, then the root certificate will be included again the next time you upgrade to a newer version of the software.
== How Mozilla Products Respond to User Changes of Root Certificates ==
The following explains how Mozilla products behave when users change or delete root certificates.
For simplicity, I will assume the basic and most common configuration, in
which you have only the software distributed by Mozilla and do not have any
additional PKCS#11 modules (with or without any additional hardware)
installed that may be capable of storing additional certificates. The
model with them is slightly more complicated than the one I'm about to
present, but only slightly.
NSS is capable of accessing certificates that have been stored in a number
of places, all accessible through the PKCS#11 API. The two places of
greatest interest are
#1) Your certificate database, which is kept in a file on disk that you can
alter. It starts out empty. Any root certificates it contains are there
because of actions that you have taken, such as downloading or importing
roots, or editing trust flags. As a rule, an update to your Mozilla
installation of a Mozilla product will not change the contents
of this database. (Rarely, it may change the FORMAT of the database, but
not the content.)
#2) Mozilla's trusted root list, kept in a read-only shared library which
is one of the files that gets updated whenever your product's executable
files get updated.
Both of these stores of certificates may contain certificates and trust
flags.
When NSS goes looking for a stored certificate, or trust flags for a stored
certificate, it first looks in your certificate database. If it finds the
certificate there, it stops. It uses whatever trust flags are there in
that database with that certificate.
If it does NOT find the certificate it wants in that database, it looks in
Mozilla's trusted root list. If it finds the cert there, then it uses the
cert and trust flags it finds there. It does not copy the cert and flags
from the root list into your database. It just uses them where and as they
are.
When you use your product's certificate manager to edit the trust flags on
a certificate, the cert manager first looks for the cert in your database,
and if it's there, then that copy gets edited. If it's not there, then
cert manager looks for a copy in the trusted cert list, and if found,
copies it and its flags into your data base, and then edits it there.
(After all, it cannot edit the copy in Mozilla's list, because that copy
is read-only.) After that, that cert will remain in your database, and
each time that the product goes looking for it, it will find it in your
database, not in the trusted list.
If you delete a cert in your database, one that is also in the trusted
list, it may appear to be completely gone, until you restart your program,
at which point it will reappear, because it never left the trusted root
list. It may reappear in the trusted root list with the trust flags from
that list. That's why we tell people that if they want to get rid of a
root, the thing to do is NOT to delete it, but rather is to take away all
its trust. (The behavior when a cert is deleted has changed a few times
over the years.)
If you edit the trust on a cert in the root list, taking away (say) one of
the 3 trust flags, but leaving the other two, then that cert and the two
trust bits will be in your cert DB. After that, if Mozilla removes that
cert completely from Mozilla's trust list, it will remain in your cert DB
with those two trust flags. Mozilla's changes to the default trust list
never affect your databases. Your databases contain what YOU put there.
They're your baby, your responsibility.
In conclusion, the changes Mozilla makes to Mozilla's read-only list of
trusted root certs affect only those certs that do not also appear in your
cert DB. When you cause copies of any of those certs to appear in your
cert DB, then you have taken control of the trust for those copies, and
changes made by Mozilla thereafter to those certs will not affect you.
