The following explains how Mozilla products behave when users change or delete root certificates.
For simplicity, I will assume the following assumes the basic and most common configuration, inwhich you have only the software distributed by Mozilla and do not have anyadditional PKCS#11 modules (with or without any additional hardware)installed that may be capable of storing additional certificates. Themodel with them is slightly more complicated than the one I'm about topresent, but only slightlydescribed here.
[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
greatest interest are
#1) Your certificate database, which is kept in a file on disk that you canalter. It starts out empty. Any root certificates it contains are therebecause of actions that you have taken, such as downloading or importingroots, or editing trust flags. As a rule, an update to your Mozillainstallation of a Mozilla product will not change the contentsof this database. (Rarely, it may change the FORMAT of the database, butnot 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.
#2) Mozilla's trusted root list, kept in a read-only shared library whichis one Both of the files that gets updated whenever your product's executablefiles get updatedthese stores of certificates may contain certificates and trust flags.
Both of these stores of certificates may contain certificates and When NSS goes looking for a stored certificate, or trustflagsfor 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.
When NSS goes looking for a stored certificate, or trust flags for a storedIf it does NOT find the certificateit wants in that database, it first looks in your certificate databaseMozilla's trusted root list. If it finds thecertificate cert there, then it uses the cert and trust flags it stopsfinds there. It does not copy the cert and flags from the root list into your database. It just uses whatever trust flags them where and as they are there inthat database with that certificate.
If it does NOT find When you use your product's certificate manager to edit the trust flags on a certificate it wants , the cert manager first looks for the cert in that your database, and if it looks inMozilla's trusted root listthere, then that copy gets edited. If it finds the cert 's not there, then it uses cert manager looks for a copy in thetrusted cert list, and trust if found, copies it and its flags into your data base, and then edits it finds there. (After all, it cannot edit the copy in Mozilla's list, because that copy is read-only.) It does not copy the After that, that cert will remain in your database, and flagsfrom each time that the root list into product goes looking for it, it will find it in your database. It just uses them where and as theyare, not in the trusted list.
When If you use your product's certificate manager to edit the trust flags ondelete a certificate, the cert manager first looks for the cert in your database,and if it's there, then one that copy gets edited. If it's not there, thencert manager looks for a copy is also in the trusted cert list, and if foundit may appear to be completely gone,copies it and its flags into until you restart your data baseprogram, and then edits at which point it there.(After allwill reappear, because it cannot edit never left the copy trusted root list. It may reappear in Mozilla's the trusted root list, because with the trust flags from that copyis read-onlylist.) After That's why we tell people thatif they want to get rid of a root, that cert will remain in your database, andeach time that the product goes looking for thing to do is NOT to delete it, it will find it in yourdatabase, not in but rather is to take away all its trust. (The behavior when a cert is deleted has changed a few times over the trusted listyears.)
If you delete edit the trust on a cert in your databasethe root list, taking away (say) one of the 3 trust flags, but leaving the other two, then that is also cert and the two trust bits will be in the trustedlistyour cert DB. After that, it may appear to be if Mozilla removes that cert completely gonefrom Mozilla's trust list, until you restart your program,at which point it will reappear, because it never left the trusted rootlist. It may reappear remain in the trusted root list your cert DB with the those two trust flags fromthat list. ThatMozilla's why we tell people that if they want changes to get rid of aroot, the thing to do is NOT to delete it, but rather is to take away allits default trustlist never affect your databases. (The behavior when a cert is deleted has changed a few timesover the yearsYour databases contain what YOU put there. They're your changes, your responsibility.)
If you edit the trust on a cert in the root list, taking away (say) one ofthe 3 trust flags, but leaving the other two, then that cert and the twotrust bits will be in your cert DB. After that, if Mozilla removes thatcert completely from Mozilla's trust list, it will remain in your cert DBwith those two trust flags. Mozilla's changes to the default trust listnever 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 oftrusted root certs affect only those certs that do not also appear in yourcert DB. When you cause copies of any of those certs to appear in yourcert DB, then you have taken control of the trust for those copies, andchanges made by Mozilla thereafter to those certs will not affect you.
