NSS tools to control CRLs and CAs
NSS (Network Security Services) is a set of OpenSource libraries used by various projects such as the Mozilla products (Firefox, Thunderbird, Seamonkey, etc.). One of the items shipped in NSS is the libnssckbi.so livrary which contains the certification authorites and the associated rights. NSS also supports CRLs but the end products do not properly use these features.
What is the issue with certification autorities shipped with NSS?
Most web navigation tools, either from Microsoft or NSS-based, are shipped with a list of certification authorities activated by default, and thus considered as "trusted" by the layman user. Of course we reckon that the default trusted list is user-friendly and avoid to ask oneself what is a "trusted" CA. The editor has already decided for him on unknown criterias (financial, technical, whatever)...
Yey this trust issue is more and more accute. The CAs are more or less free to decide which verifications are needed to issue a certificate as long as it's described in their CPS. Nowadays some authorities issue certificates with quite different verification levels. We believe that some practices are questionnable, if not dangerous (1-factor certificates = Domain-Validated) and harm the trust the end user places in his SSL/TLS browser.
At TBS Internet, we are concerned by trust issues since 1996 when we startedissuing SSL certificates (we are a major certificate wholeseller in France). We needed to find a solution to apply to our own staff's browsers in order to trust only CAs that we trusted. Those CAs are mainly those we know and work with, and which deliver 3-factor (organisation) or EV certs.
We have therefore developped a simple tool to desactivate all the root certs but those we have listed as trusted. It enables us to associate a specific trust level to them.
What is the issue with NSS-based products and CRLs?
The NNS-based products have a major fault: they don't use the CRL functions. In Firefox 3 for example, it is possible to configure CRLs manually, but none is shipped with it! It's completly weird to ship a product with 120+ root CAs but no CRLs to check the issued certs. However a (geek) user can manually import a CRL... but then he will be faced with a dangerous bug: the CRL auto update feature does not work! (see bug 371522)
Those are 2 major faults: CRLs are not shipped by default and manually imported CRLs cannot be automatically maintained uptodate! We have therefore developped a simple tool which downloads and imports CRLs into the NSS user database. Of course this fix is not perfect: the CRL list is static and some CRLs of intermediate certificates used to issue certs from trusted CAs are missing.
It's important to figure out that IE7 and Opera 9.5 properly implement and use CRLs by default. Since the massive revocation of certificates due to the Debian OpenSSL bug, the automatic check of the CRLs is a required security feature. On this issue, Firefox 3 is bad, and we are waiting for the support of crlDistributionPoint with great impatience (see bug 321755).
Prerequisite to use our tools
We provide our tools under Artistic licence. Those tools are in use and have been tailed to our company needs. They work for Linux, but it is certainly possible to adapt them to Windows or MacOS. Our tools are provided with our data files; you will need to customize them for YOURS.
Our tools require:
- certutil and crlutil binaries provided in most distributions by libnss3-tools or mozilla-nss-tools packages. We recommand using NSS version 3.11 or above (we didn't test older versions).
- bash
- perl
- curl
- cron
Please backup your cert8.db and key3.db files before hand.
nss_update_crl: CRLs update
The nss_update_crl script takes a single parameter: the path to the directory containing your cert8.db file. There is a directory for each user profile created by your mozilla product ((Firefox, Mozilla, Seamonkey, Thunderbird). Check in your~/.mozilla/firefox/(profile name)/ oor ~/.thunderbird/(profile name)>/ ou ~/.mozilla-thunderbird/(profile name)/ . The profile name has a format such as xxxxxxxx.slt or xxxxxxxx.default.
To launch the script, call it with nss_update_crl ~/.mozilla/firefox/(profile name)/ on a command line. We advise to put the script in ~/bin/.
The script reads a data file containing the CRLs to be loaded. This file is expected in ~/bin/nss_update_crl.list by default. CAUTION: the file we offer is ours and matches our own security policy (restricted list of CAs, see below). It's up to you to check it out and add other CRLs of CAs you might trust.
The structure of ~/bin/nss_update_crl.list is simple : all the lines contains a URL of a CRL to be imported, except those which start by a pound sign (#).
Whem import fails (it happens), a directory in ~/tmp/nss_update_crl-error-xxxxxxxxxx/ is left behinf with the URL, the error message and the CRL file.
Once the program tested by hand, we recommand to use cron to update the CRLs periodically and automatically. Therefore, use the following example and choose a random value between 0 and 59 instead of ZZ (so that we don't all download at the same minute). You may also change the hours value (9,11,15,19).
ZZ 9,11,15,19 * * * ~/bin/nss_update_crl ~/.mozilla/firefox/(profile name)/nss_restrict_ca: trusted CA limitation
The nss_restrict_ca script takes a single parameter: the path to the directory containing your cert8.db file. There is a directory for each user profile created by your mozilla product ((Firefox, Mozilla, Seamonkey, Thunderbird). Check in your~/.mozilla/firefox/(profile name)/ oor ~/.thunderbird/(profile name)>/ ou ~/.mozilla-thunderbird/(profile name)/ . The profile name has a format such as xxxxxxxx.slt or xxxxxxxx.default.
The script will use the software security device as the default. It can also work on the libnssckbi.so store: Builtin Object Token. You need then need to specify --builtin as the first parameter (in from the of directory path).
The script reads a data file with the certificates to be trusted. This file is expected in ~/bin/nss_restrict_ca.list by default. CAUTION the file we offer is ours and matches our own security policy (restricted CA list). It's up to you to check it out and add other CAs you might trust. Please backup your cert8.db before first use.
The script's logic is simple: any CA found it NSS's store which is not specifically documented in our data file is desactivated. If a match is found, then the rights contained in our data file are applied. Therefore we enforce that only CAs declared in our file and associated rights are in use.
The syntax of our data file is composed of comments (lines start with a pound sign (#)), and of lines such as:
(name of authority) (NSS flags)The autority name must exactly match the name in the NSS database, which is the name you see with:
certutil -L -d path_to_your_profile or certutil -L -h "Builtin Object Token" -d path_to_your_profileFor the meaning of the NSS flags, see NSS trustargs documentation
To create your data file, you may uncomment lines we left in or add comments. On first launch, you will be displayed the list of desactivated certs. Examine it precisely to amend your file. It is usually not needed to give rights to intermediate certs, except when they are part of your own personnal certificate.
Please note our tool does not import any CA in the NSS database. Adding a cert description in the data file will have no effect if the cert is not already in the database.
We advise to close your browsers while running the tool the first times (to avoid concurrency issues as there are many changes). Once the program tested by hand, we recommand to use cron to enforce the CA policy periodically and automatically. That will let you desactivate any certificate that an end user would have added or reset some changes made (in this case, a warning is displayed).
To do so, use the following lines and eventually change the minutes and hours.
1 12 * * * ~/bin/nss_restrict_ca --builtin ~/.mozilla/firefox/(profile name)/ 2 12 * * * ~/bin/nss_restrict_ca ~/.mozilla/firefox/(profile name)/Our tests have shown a strange behavior when we work on the software store, that"s why we advise to call the program twice on the 2 stores.
Finaly
We use those 2 tools on our staff computers. They enable use to enforce that only the CAs we, at a management level, trust are in use. Users are no longer fooled with low authentication certs.
Controlling the CA used also help to load all the appropriate CRLs. Thus users are properly warned when they hit a revoked cert.
Download V1.0
After ass this reading, the download takes place here:
2009 Improvments (v2.0)
In 2009, we improved the scripts to enable management under root with nss_root_util. This script handles all the users of a workstation. It can enforce a global policy and make exceptions locally for a user. We also added to the original tools the capability to test cert8.db after modification. We noticed that certutil often corrupts cert8.db.
Download V2.0
Feedback
A commentaire regarding this article ? Our opinion is valuable to us. Please write to tag-nss-tools@TBS-internet.com
Our prices are in GBP VAT-less and order-time payment, see also our general sales terms.