GNOME Bugzilla – Bug 585300
support gnome-keyring PKCS#11 provider for NSS certificate store
Last modified: 2018-12-11 15:31:21 UTC
Evolution maintains an internal certificate store in NSS, currently used for S/MIME certificates (but with the patch on bug 270393 can also be used for client cert auth for SSL/TLS). However, users don't always have certificates as PKCS#12 files that can be imported into the NSS certificate store - the certificate may be on a smart card, for example. Even if they do have a PKCS#12 file, they ideally wouldn't have to import it separately into every application. GNOME provides a way to avoid having to do so, in the form of the gnome-keyring daemon. gkr has a PKCS#11 module that lets NSS use certificates imported into gkr directly, so any certificate in gkr is used automatically by Evolution. All that's required to enable this is to load the NSS provider module for gkr when initilizing NSS in camel in e-d-s. The attached patch is a dirty hack that enables g-k-r loading using a fixed path to the library. It works well enough as a demo: you can see any certificates in gkr's certificate store in the Evo "Your Certificates" page in preferences. Even after deleting the cert8.db and key3.db nss store files to ensure the cert isn't in Evo's local cert store the certs in gkr are still shown. I intend to replace this patch with one that adds UI to the "Certificates" panel in evo to allow the addition of new PKCS#11 providers. By default, the provider list would include a provider for gnome-keyring ( /usr/lib/gnome-keyring/gnome-keyring-pkcs11.so ) but users could add others, like smartcard readers. Note that Evolution can support client certificates for SSL/TLS negotiation and authentication with a simple change - see bug 270893 - and with this patch as well, client certificates will be found in gnome-keyring, smartcard readers, etc as well as in Evolution's internal certificate store. The main intent of this patch is to be used with the patch adding client-certificate support to allow Evolution to use gnome-keyring's cert store for client cert auth.
Created attachment 136240 [details] [review] Initial demo patch to enable using gkr's certificate store in Evo
The same result can be achieved by modifying secmod.db using modutil from libnss3-tools (Ubuntu). The command: modutil \ -dbdir $HOME/.evolution \ -add GnomeKeyring -libfile /usr/lib/gnome-keyring/gnome-keyring-pkcs11.so will tell NSS to load the Gnome Keyring PKCS#11 provider and use it. Evolution does not even need to know about it. You can see which providers are currently loaded with: modutil -dbdir $HOME/.evolution -list A change is still needed ... somewhere ... in that gkr's PKCS#11 provider should probably added by default when running under GNOME. It's not clear whether this should be done by Evolution, by some NSS configuration, or elsewhere; I'd need advice from someone who knows the NSS infrastructure better. Ideas?
Oh, I should've mentioned: To import a key into gnome-keyring, use "gnome-keyring import /path/to/certificate.p12"
Fedora has been doing some work related to this: http://fedoraproject.org/wiki/FedoraCryptoConsolidation
It seems to me that you are able to instruct gnome-keyring-daemon to use the pkcs11 module system wide,thus there is no need to have any change in evolution code for its support. Maybe just people don't know about it (yet). see > $ gnome-keyring-daemon --help > > ... > -c, --components=ssh,pkcs11 The optional components to run I suppose it's used for things you need. I'm not sure if I got your proposed UI change above correctly, was it "just" a fancy tuning of the UI to differentiate between certificates from gnome-keyring and those stored in evolution only? That might be nice, I guess.
Craig, could you elaborate on your proposed changes as asked in comment #5? Thanks in advance!
If gnome-keyring is running a PKCS#11 provider (using -c pkcs11), evo still needs to tell the nss crypto libraries that gkr has a pkcs#11 provider and how to use it. To do so, it must load the pkcs#11 provider library for gkr, which is what the proposed change is for. What Milan is talking about is the gkr server side provider. Evo needs to load the client for it, allowing libnss to talk to gkr's pkcs#11 provider. So this change is still needed. ( BTW, this is completely useless if Evo is built with gnutls instead of NSS. NSS is a full featured crypto provider and store, where gnutls is just a set of algorithm implementations. Current versions of GnuTLS know nothing about PKCS#11 and cannot use it; they expect the app to provide key material. Hopefully Evo will drop GnuTLS support in favour of a cross-app-shared libnss using the sqlite backend, or GnuTLS's new and experimental PKCS#11 support will mature, but until then this is only useful for libnss builds. ) Related: https://bugzilla.gnome.org/show_bug.cgi?id=585214 Related: https://bugzilla.gnome.org/show_bug.cgi?id=585301
The things changed meanwhile. Camel used to use NSS also for connections, but it relies on glib (and glib-networking) for some time now. The NSS is used only for certificate handling, like for S/MIME. Your workaround from comment #2 would be better probably, but the Camel doesn't have its own secmod.db anymore, it uses the system one, as you also mentioned above would be a good step, thus modifying that one as you showed in comment #2 will allow adding the module for any application using NSS, which is much better, thus I'm closing this in favor of a more generic way to achieve (almost) the same.