Closed Bug 449498 Opened 13 years ago Closed 7 months ago

Open secondary (additional) read-only system NSS database


(NSS :: Libraries, defect)

Not set


(Not tracked)



(Reporter: KaiE, Unassigned, NeedInfo)



(Whiteboard: [psm-shared-db])


(1 file, 1 obsolete file)

Fedora has started to ship an NSS database in the OS global location /etc/pki/nssdb, which contains system-wide certificates or security modules that all applications should have access to.

I think the proposal is to open that additional database automatically on NSS init time.

We'd like to do this at least on Linux, and maybe we should start with #ifdef'ed code.
We could add other platforms, too, if there is interest and a standardized location for this kind of database (with the initial version or at a later time).
It shouldn't be an additional database; the application should open sql:/etc/pki/nssdb _instead_ of its old database. The module automatically handles opening the user's own database in ~/.pki/nssdb as an 'overlay'.

With the NSS bugs fixed as described in this works as expected; merging the old DBM database from the profile directory into the user's SQL database. If the system database isn't configured, then it just uses the DBM database as before.
Attachment #451345 - Attachment is obsolete: true
This bug was initially filed against the NSS component with the expectation to
Whiteboard: [psm-shared-db]
David, Are you requesting that this patch be reviewed and considered for 
inclusion?  Or is this merely a "work in progress"?  

If you believe this patch is ready for submission, please request that it 
be reviewed by
Comment on attachment 451412 [details] [diff] [review]
revised patch to try system db only on unix

I think it's ready for inclusion. There are NSS bugs which need to be fixed -- but this part only triggers if the system NSS DB is enabled anyway; if it's not enabled you get the old behaviour.
Attachment #451412 - Flags: review?(kaie)
Comment on attachment 451412 [details] [diff] [review]
revised patch to try system db only on unix

Bob Relyea is the best person to review this patch.

Bob, it'd be bad if an application had to read pkcs11.txt
directly and look for "".

This should be done by the NSS initialization functions.
If we have a good error code that NSS initialization functions
can return to indicate a missing pkcs11.txt unambiguously,
an application can simply try initializing NSS with
"sql:/etc/pki/nssdb", and fall back on the home/profile
directory if it gets that error code.
Attachment #451412 - Flags: review?(rrelyea)
(In reply to comment #6)
> Bob, it'd be bad if an application had to read pkcs11.txt
> directly and look for "".

Yeah, it sucks that we have to do this.


I'd rather have NSS just do the right thing rather than returning an error when we attempt to open sql:/etc/pki/nssdb r/w though.
Comment on attachment 451412 [details] [diff] [review]
revised patch to try system db only on unix

Way behind on my reviews. I'm OK with this patch with the following caveats.

1) this is PSM code so Kai should have the final say since he'll have to support what goes in.
2) explicity checking for may fail in the future is we support some admin tool that replaces libnsssysinit with something that gets the nss configuration from some admin repository.

#1 is the more critical issue.

Attachment #451412 - Flags: review?(rrelyea) → review+
Having talked to people about GNOME keyring plans at GUADEC this week, I'm a little bothered by your #2 too. I can envisage a situation where we point at a GNOME-keyring PKCS#11 module directly from /etc/pki/nssdb, instead of using libnsssysinit. (Although maybe we'd be more likely to put that in the user's pkcs11.txt instead.)

Should we make it trigger if *any* module would be loaded by the /etc/pki/nssdb/pkcs11.txt file, rather than just ?
This patch uses 

Unless I missed something new, in my understanding, this may require multiple master password prompts. This is necessary if the old profile db uses a different password than the user's shared db in ~/.pki/nssdb

If this is true, in my understanding, we must use application assisted merging.

This document lists a proposal of how this could be done:

If you agree with me that application assisted merging is necessary, I believe this patch is r-
Duplicate of this bug: 620373
Attachment #451412 - Flags: review?(kaie) → review-
Using Mozilla products in a corporate context is really inconvenient due to this issue. All our users have to individually import our CA certificate because FF and TB don't read it from the available /etc/pki/nssdb files.
The derailment of this bug is caused by a requirement that has nothing to do with this bug.
This bug is supposed to be about using a read-only, system-wide NSS database, however the blocking issue has to do with the fact that somewhere along the line, the decision was to ALSO remove the separate per-user NSS databases used by, e.g. firefox and thunderbird (which are currently stored in profile directory) and instead making a single per-user read-write database stored at, e.g. ~/.pki/nssdb

And while I understand that this is also a desirable outcome, does it have anything to do with allowing site-wide use of TB without having users be forced to hand-configure their TB before accessing corporate mail servers protected with internal CA, which is the essence of THIS bug report?  It doesn't seem the two are actually related...

Any chance that progress could be made on this?
kai, can you switch this bug to PSM? Both the patch and the ultimate solution are PSM issues.

Any progress on this yet? As was mentioned earlier, this can be a major inconvenience in an enterprise environment.
FWIW the trust issue has mostly been solved. Fedora for example ships as a replacement for NSS's It provides all the trust roots in the place that NSS *expects* them to come from.
I'm not sure this bug has been completely fixed. I'm running Ubuntu 15.04 and it's not picking up certificates that the rest of the system is picking up (I checked that curl and wget were fetching the URL's correctly while verifying certificates).
Are you referring to my comment 16? You do need your distribution to ship in place of Mozilla's, so it has a consistent set of trusted CAs with the rest of the system.
Probably relates to bug 454036 and should be platform all
Closed: 7 months ago
QA Contact: jjones
Resolution: --- → WONTFIX

@J.C. Jones Can you kindly undo your recent change to the status of this bug?

@David Woodhouse: only handles CA certificates; it does not pull in the PKCS#11 security module configuration, which is stored in the system-wide NSS database. This is required where smart cards are used (using security modules such as OpenSC, either directly or via the p11-kit-proxy security module). This was part of the issue reported with this bug.

As it stands now, the PKCS#11 module configuration still has to be manually added to every Firefox/Thunderbird profile after the application is first launched by the user and the NSS databases are created at that time. Changes to the system-wide NSS database won't propagate (for example, if the system administrator replaces the CoolKey module with OpenSC).

Flags: needinfo?(jjones)

David, I presume you are running on Linux? If your firefox/thunderbird is build with policy enabled, you can add the line to our policy file:


On Fedora or RHEL 8 the policy file is in /etc/crypto-policies/back-ends/nss.config.
On RHEL7 it's in /etc/pki/nss-legacy/nss-rhel7.config

For other distributions look at the build scripts for POLICY_FILE and POLICY_PATH.


Let me know if Bob's advice here isn't a good resolution. Otherwise, I don't see us changing NSS' behavior to load multiple SQLite databases.

Flags: needinfo?(jjones) → needinfo?(david.ward)
You need to log in before you can comment on or make changes to this bug.