On Thu, 2014-12-04 at 11:07 +0000, Martinsson Patrik wrote: > On a standard Rhel 7 installation, the pkcs11.txt under /etc/pki/nssdb > *only* contains, > > library=libnsssysinit.so > ...
> And this is a good thing as it will dynamically load the users > ~/.pki/nssdb in read-write mode on top of the read-only /etc/pki/nssdb > so users can set up their on trusts etc., correct ? Right. Although note that the problem you wanted to solve by using the NSS Shared System Database in /etc/pki/nssdb is solved *differently* by using p11-kit. So you might do yourself a favour by running 'setup-nsssysinit off' and forgetting it ever existed. > If I then use 'pkcs11_inspect debug' for verifying my self-signed > certificate (and having the CA's certificate > under /etc/pki/ca-trust/source/anchors/ && update-ca-trust) the > verifcation *fails*. > > If I then add the following lines to /etc/pki/nssdb/pkcs11.txt > library=libnssckbi.so > name=libnssckbi > NSS=trustOrder=100 > > (and libnssckbi.so points to alternatives, which points to > p11-kit-trust). > > You say that this shouldn't be necessary (and probably a bug), just to > clarify things for me, do you mean that, > > 1 ) "adding the libnssckbi.so to shouldn't be necessary since it should > already be there from the beginning, and that the bug is that the > library is missing from the default setup", or That one. libnssckbi.so is what provides the default trust roots. It's *always* supposed to be loaded in an NSS system. You shouldn't need to add it manually. I don't. (Note that you also shouldn't need to add your CAs to the actual sqlite database in /etc/pki/nssdb either, since they should be coming from your "libnssckbi.so" which is actually p11-kit.) > Now the libp11-proxy, > > > I worked around it by symlinking /usr/lib64/libnssckbi.so to > > p11-kit-proxy.so instead of p11-kit-trust.so, which gives me the trust > > roots *and* the other loaded modules. That one probably ought to be > > the default. > > Ok, I did the same thing. Using the alternatives system. > > > > Firefox only asks me to log into my p11-kit-provided hardware tokens > > > > when I go to a web site which wants a certificate, which is fair > > > > enough. > > Yes, same behavior here, I was mistaken when I stated that it actually > asked for pins to GNOME keyring and the Secret Store. > Firefox behaves in my opinion as expected, and I don't need to "manually > mess" with the users nssdb - the default will just work as I expect > (trusting my CA and ask for PIN to hardware token when requested). Did you have to manually add libnssckbi to Firefox too? Remember, that uses its own database and not sql:/etc/pki/nssdb. > > Evolution does ask for a PIN for GNOME keyring and the Secret Store. > > Stef suggests that's because Evolution doesn't handle > > CKF_PROTECTED_AUTHENTICATION_PATH. I filed this bug for that: > > https://bugzilla.gnome.org/show_bug.cgi?id=741059 > > Cool, then we have the same behavior and a possible reason for why it > behaves like it does. The same thing goes for chrome, I'll file a > bug-report to those ppl referring to this bug. Chrome uses sql:$HOME/.pki/nssdb and not sql:/etc/pki/nssdb. Did you add libnssckbi.so to *that* one? (Evolution will use sql:/etc/pki/nssdb *if* it's enabled, and sql:$HOME/.pki/nssdb if not. A piece of horridness fundamental to the "design" of the NSS Shared System Database.) > breaks pam_pkcs11. Using the above config, pkcs11_inspect throws the > following, >... > DEBUG:pkcs11_lib.c:272: loading Module explictly, > moduleSpec=<library="/usr/lib64/pkcs11/opensc-pkcs11.so" > name="SmartCard"> module=/usr/lib64/pkcs11/opensc-pkcs11.so > DEBUG:pkcs11_lib.c:276: Failed to load SmartCard software (null) > ERROR:pkcs11_inspect.c:73: > load_pkcs11_module(/usr/lib64/pkcs11/opensc-pkcs11.so) failed: > Not really sure why this happens, but changing the lines, I suspect this is because it's trying to explicitly load opensc-pkcs11.so when it was *already* loaded. I wonder if works better if you point it at p11-kit-proxy.so instead. Not sure if that can cope better with multiple initialisations, if such a thing is even possible. Further discussion of that might be more appropriately targeted to the OpenSC mailing list, since pam_pkcs11 is theirs too. In the meantime, given the bug that libnssckbi.so doesn't seem to show up for you unless explicitly requested, a potential workaround might be to point pam_pksc11 at a NSS DB which *doesn't* request it (it can request p11-kit-trust.so instead). -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
