Confirmed users, Administrators
5,526
edits
| Line 41: | Line 41: | ||
The following explains how Mozilla products behave when users change or delete root certificates. | The following explains how Mozilla products behave when users change or delete root certificates. | ||
For simplicity, | For simplicity, the following assumes the basic and most common configuration, in which you have only the software distributed by Mozilla and do not have any | ||
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 described here. | ||
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 | |||
NSS is capable of accessing certificates that have been stored in a number | [http://www.mozilla.org/projects/security/pki/nss/ Network Security Services (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 | of places, all accessible through the PKCS#11 API. The two places of | ||
greatest interest are | greatest interest are | ||
# | # 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.) | ||
alter. It starts out empty. Any root certificates it contains are there | #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. | ||
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.) | |||
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. | |||
flags. | |||
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. | |||
certificate, it | |||
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. | |||
cert and | |||
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.) | |||
a | |||
If you | 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 changes, 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. | |||
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. | |||