Fixing NSS and p11-kit in Fedora (and beyond)

David Woodhouse dwmw2 at
Thu Dec 11 01:12:14 PST 2014

I'd love to have a Fedora Feature in F22 for PKCS#11, where keys+certs
from installed PKCS#11 modules are expected to Just Work™ in all
applications that can use certificates. Using consistent PKCS#11 URIs
where appropriate. Even if we aren't ready for a Feature, I'd love to
make some more progress in that direction. Obviously none of this is
really Fedora-specific, but if we can get it right in Fedora (as we did
for the trust stuff), other distributions can follow.

(For now I'm going to gloss over the UI implications, partly discussed
in and at least for
NetworkManager, and concentrate on the back end).

With GnuTLS-using applications we're fairly much already there. It
mostly just does the right thing and accepts PKCS#11 URIs in place of
filenames. Yay Nikos! :)

With OpenSSL there's ENGINE_PKCS11, and I have a proof-of-concept patch
to make it load instead of *having* to be told which
module to load, and to make it use PKCS#11 URIs. So although OpenSSL is
painful, it's a tractable problem. I've got OpenConnect, for example,
using standard PKCS#11 URIs and Just Working when built with OpenSSL.

OpenVPN also uses OpenSSL but without the ENGINE; it uses pkcs11-helper
instead. I've also fixed *that* to use PKCS#11 URIs for its
serialization format:

Then there's NSS, and there are a few things we (might) need to address.

The PKCS#11 URI thing is probably simple enough — we can provide a
helper function which iterates over the available tokens in NSS and
finds an object matching a given URI. And which generates a URI for a
given object, if that's required. But in a pure GUI application like
Firefox/Chrome/Evolution/Thunderbird this isn't relevant. They have
their own certificate choosers. And I already said I was going to gloss
over the need for GCR to do this sanely for us in the general case.

So the main interesting question is how we get NSS to automatically load
the PKCS#11 modules that are configured in p11-kit.

Note that NSS applications *sometimes* want the system trust database to
be present (and will load if so), and sometimes don't.

NSS applications should theoretically use one of the two databases
in /etc/pki/nssdb, but often (Firefox, Thunderbird, Chrome, etc.) don't.

In Fedora we have already hijacked NSS's own with the
trust roots, and symlinked it to to give the trust
database configured by the sysadmin.

So here are some of the options for making NSS apps behave nicely:

 - Add to {sql:,}/etc/pki/nssdb modules list

This works for the NSS applications which actually *use* /etc/pki/nssdb.
Which is relatively few of them. I've fixed Evolution to do so, but even
then it'll *only* do so if the NSS "Shared System Database" is enabled,
which provides an 'overlay' from $HOME/.pki/nssdb. Otherwise you end up
with a read-only database which is not acceptable for most applications.

It also has the problem that it's loading the default trust, even into
applications which didn't *want* that. So if we do this (or most of the
other options below, in fact), we'd probably want to load in a mode which *doesn't* load the System Trust and
Default Trust slots.

 - Symlink to instead of

This actually worked fairly nicely in testing. It *does* fix Firefox and
Chrome, etc., and indeed *most* user-facing applications, since most of
them *do* want the system trust and do load But there are
some things, like pam_pkcs11, which *don't* load the system trust but
which *should* have the p11-kit PKCS#11 modules loaded. Perhaps we could
explicitly configure them to load (-trust) for

 - Explicitly add SECMOD_LoadUserModule( to apps

We *could* do a bombing run on the relevant applications and make them
all load (-trust) explicitly for themselves.

Let's not.

 - Modify NSS to automatically load p11-kit modules.

Maybe slightly saner than hacking the apps, we could make NSS
automatically load (-trust) whenever the database is
initialised. Or even better, perhaps it could use p11-kit and
p11_kit_modules_load() directly instead of

I don't know how much resistance there would be to doing this kind of
thing *in* NSS, or what the disadvantages would be. But at first cut,
this seems like it might be the best solution. And if it's done *in* NSS
then we can make a sane decision about which of the NSS_Init* functions
should do this, and which (perhaps NSS_NoDB_Init() for example) should
not. I'll largely defer to Bob for NSS expertise and strategic direction

Any thoughts on how best to sort this out would be much appreciated. We
need to do *something*, but it's not entirely clear what.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <>

More information about the p11-glue mailing list