Hi again David (and everyone else),
Thanks again for all the explanations, it certainly (again) makes stuff
clearer and I now seem to have an reasonable idea about whats going on
and how to handle our situation.
On a standard Rhel 7 installation, the pkcs11.txt under /etc/pki/nssdb
*only* contains,
library=libnsssysinit.so
name=NSS Internal PKCS #11 Module
parameters=configdir='.' certPrefix='' keyPrefix='' secmod='' flags=
updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid=''
updateTokenDescription=''
NSS=Flags=internal,moduleDBOnly,critical trustOrder=75 cipherOrder=100
slotParams=(1={slotFlags=[RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,MD2,SSL,TLS,AES,Camellia,SEED,SHA256,SHA512]
askpw=any timeout=30})
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 ?
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
2 ) "the module shouldn't need to be in the nssdb at all since this
should be handled in some other way (please expand on that part if that
's the case)"
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).
> 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.
Now, the interesting thing, it seems (at least to me in my setup) that
having a system where,
- libnssckbi.so -> alternatives -> p11-kit-proxy.so
- /etc/pki/nssdb/pkcs11.txt contains,
library=libnsssysinit.so
name=NSS Internal PKCS #11 Module
parameters=configdir='.' certPrefix='' keyPrefix='' secmod='' flags=
updatedir='' updateCertPrefix='' updateKeyPrefix='' updateid=''
updateTokenDescription=''
NSS=Flags=internal,moduleDBOnly,critical trustOrder=75 cipherOrder=100
slotParams=(1={slotFlags=[RSA,DSA,DH,RC2,RC4,DES,RANDOM,SHA1,MD5,MD2,SSL,TLS,AES,Camellia,SEED,SHA256,SHA512]
askpw=any timeout=30})
library=libnssckbi.so
name=libnssckbi
NSS=trustOrder=100
breaks pam_pkcs11. Using the above config, pkcs11_inspect throws the
following,
DEBUG:pam_config.c:238: Using config
file /etc/pam_pkcs11/pam_pkcs11.conf
DEBUG:pkcs11_lib.c:182: Initializing NSS ...
DEBUG:pkcs11_lib.c:192: Initializing NSS ... database=sql:/etc/pki/nssdb
DEBUG:pkcs11_lib.c:210: ... NSS Complete
DEBUG:pkcs11_inspect.c:69: loading pkcs #11 module...
DEBUG:pkcs11_lib.c:222: Looking up module in list
DEBUG:pkcs11_lib.c:225: modList = 0xa4bb70 next = 0x108fe50
DEBUG:pkcs11_lib.c:226: dllName= <null>
DEBUG:pkcs11_lib.c:225: modList = 0x108fe50 next = 0x0
DEBUG:pkcs11_lib.c:226: dllName= libnssckbi.so
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,
library=libnssckbi.so
name=libnssckbi
NSS=trustOrder=100
to explicitly load p11-kit-trust (instead of loading it through the
p11-kit-proxy),
library=/usr/lib64/pkcs11/p11-kit-trust.so
name=libnssckbi
NSS=trustOrder=100
works as expected.
Any thoughts on why ?
I don't mind having the /etc/pki/nssdb/pkcs11.txt load
the /usr/lib64/libnsssysinit.so and /usr/lib64/pkcs11/p11-kit-trust.so,
i just *thought* that I would be able to use the p11-kit-proxy for
loading p11-kit-trust for me (and whatever other modules p11-kit is
configured for).
Again, a big thank you for clearing this "mess" up and filing those
bug-reports. I would love to see this area to "just work" in the future
(as seahorse, I haven't done any configuration and that thing just works
as I expect). I still don't understand why Mozilla is using their own
nssdb, but since re-linking libnssckbi to p11-kit-proxy it doesn't
really matter to me from a sysadmin perspective.
Best regards,
Patrik Martinsson,
Sweden
Tue, 2014-12-02 at 18:58 +0000, David Woodhouse wrote:
> On Tue, 2014-12-02 at 18:24 +0000, Martinsson Patrik wrote:
>
> > So here's a round of new questions,
> >
> > - There are different ways of loading pkcs11-modules into an application
> > where nss is one and p11-kit is another. And where p11-kit is a library
> > that an application can link to, and where nss is a database that an
> > application opens. And if an application is not linked to libp11-kit, we
> > can use p11-kit-proxy in our nssdb to get "all the features" of p11-kit.
> > Is the above somewhat correct ?
>
> Maybe not "all the features", but the tokens should be visible and
> usable. You don't get to reference objects by PKCS#11 URIs and things
> like that.
>
>
> > - We put out CA in '/etc/pki/ca-trust/source/anchors/', and import
> > '/usr/lib64/libnssckbi.so' into our 'sql:/etc/pki/nssdb'.
>
> I'm confused about that. Why would you have to explicitly
> *add* /usr/lib64/libnssckbi.so? That's supposed to be there
> automatically, already.
>
> It contains the default trust roots, in a hard-coded library.
>
> > Everything works as I expect, great! But how is libnssckbi.so relevant
> > to '/etc/pki/ca-trust/source/anchors/' and/or to p11-kit.
>
> What happens is that p11-kit-trust actually *replaces* the NSS version
> of /usr/lib64/libnssckbi.so with its own, to actually be configurable
> and consistent with the rest of the system. So /usr/lib64/libnssckbi.so
> on your system may actually be the p11-kit one, which does use the stuff
> from /etc/pki/ca-trust.
>
>
> > I'm having
> > trouble sorting out and understanding these components. If I remove
> > libnssckbi.so from 'sql:/etc/pki/nssdb' validation of
> > self-signed-certificats fails (which must mean that libnssckbi.so adds
> > my trusted anchors, right ?).
>
> That one confuses me too. I suspect it's a bug. Possibly due to the
> p11-kit 'imposter' version of the module, but I'm not sure.
>
> > I have now "solved" our different issues like this,
> >
> > "Have all kinds of applications trust our CA."
> > Seems to work with just,
> > 1) Put CA in '/etc/pki/ca-trust/source/anchors/'
> > 2) Import 'libnssckbi.so' into 'sql:/etc/pki/nssdb'
> > 3) Run 'update-ca-trust'
>
> Step 2 *really* shouldn't be necessary. I think you should file a Red
> Hat bug for that with a simple test case, as long as you have run
> 'update-ca-trust enable' as Miroslav suggests.
>
> > I've also removed the 'libnsssysinit.so' from 'sql://etc/pki/nssdb' and
> > everything still seems to work as expected. Do I need it, and if so,
> > why ?
>
> That will be responsible for loading the read-write database from
> ~/.pki/nssdb on of of the read-only system database. So if users want to
> be able to store their *own* trust settings and certificates, you'll
> want it.
>
> > So, basically we got our CA and smartcard-implementaion working pretty
> > well.
> > Maybe it can be done differently and better, but after spending *a lot*
> > of time on this matter I just feel "whatever works".
>
> Yeah, that makes sense. It would be really good to get this to the point
> where it Just Works and people don't have to jump through so many hoops.
>
> > Edit:
> > I quickly tried to import libp11-proxy.so in the users nssdb (and
> > in .mozillas) and it worked as expected. However, since all my
> > "keyrings" (?) now are in the slots, evolution (and chrome/ff etc) now
> > asks me for passwords to all my "keyrings" (when going into preferences
> > that is in evolution, or security devices in ff, or manage certificates
> > in chrome) which are "Smartcard", "Gnome2 Key Storage", "Secret Store".
> > I do however get a question about "unlocking the gnome2-keyring" at
> > login (can't remember if it was the same for the secret store"), however
> > it just seemed oddly designed from a user-perspective. Unlocking the
> > "smartcard" when performing the action above I can explain to our ~150
> > desktop-users, however I just feel it's going to be hassle to try to
> > explain all the different keyrings that would be available in the
> > p11-kit-proxy-slots. But maybe I'm missing something here ?
>
> Yeah, not sure why it should be doing that. I don't remember it doing
> so; will retest with p11-kit-proxy in my NSS stack.
>
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
