Re: libnsssysinit
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
Re: libnsssysinit
On Thu, 2014-12-04 at 11:31 +, David Woodhouse wrote: 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. ... except in the specific case where I was testing pam_pkcs11. https://bugzilla.redhat.com/show_bug.cgi?id=1170587 -- dwmw2 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
Re: libnsssysinit
On 12/04/2014 03:31 AM, David Woodhouse wrote: 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. Huh? that is not true. libnssckbi.so is loaded by nssysinit, or by the application or by someone explicitly loading it into the pkcs11.txt/secmod.db. It is not loaded automatically by every nss application. I believe the p11-kit does some magic to get it loaded for mozilla and the root store. Kai worked with stef to get that working, kai do you recall how that hooks in? bob (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). 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
Re: libnsssysinit
On Thu, 2014-12-04 at 10:33 -0800, Robert Relyea wrote: 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. Huh? that is not true. libnssckbi.so is loaded by nssysinit, or by the application or by someone explicitly loading it into the pkcs11.txt/secmod.db. It is not loaded automatically by every nss application. OK... but applications such as firefox which actually want trust to work should be loading it, right? Yes, there are some applications which use NSS only for private crypto purposes and don't need the trust roots, but Patrik seemed to be suggesting that in RHEL, even Firefox wasn't loading libnssckbi.so until he manually added it to pkcs11.txt/secmod.db. I believe the p11-kit does some magic to get it loaded for mozilla and the root store. Kai worked with stef to get that working, kai do you recall how that hooks in? I thought we really were just replacing libnssckbi.so with our own. Which is fine as long as it's actually being loaded. -- dwmw2 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
Re: libnsssysinit
Yes, there are some applications which use NSS only for private crypto purposes and don't need the trust roots, but Patrik seemed to be suggesting that in RHEL, even Firefox wasn't loading libnssckbi.so until he manually added it to pkcs11.txt/secmod.db. Maybe I should have been clearer from the beginning, it was actually just pam_pkcs11 that didn't automatically picked up my CA, sorry if it got confusing. /Patrik Sent from Ninehttp://www.9folders.com/ From: David Woodhouse dw...@infradead.org Sent: Dec 4, 2014 11:02 PM To: Robert Relyea Cc: dev-tech-crypto@lists.mozilla.org Subject: Re: libnsssysinit On Thu, 2014-12-04 at 10:33 -0800, Robert Relyea wrote: 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. Huh? that is not true. libnssckbi.so is loaded by nssysinit, or by the application or by someone explicitly loading it into the pkcs11.txt/secmod.db. It is not loaded automatically by every nss application. OK... but applications such as firefox which actually want trust to work should be loading it, right? Yes, there are some applications which use NSS only for private crypto purposes and don't need the trust roots, but Patrik seemed to be suggesting that in RHEL, even Firefox wasn't loading libnssckbi.so until he manually added it to pkcs11.txt/secmod.db. I believe the p11-kit does some magic to get it loaded for mozilla and the root store. Kai worked with stef to get that working, kai do you recall how that hooks in? I thought we really were just replacing libnssckbi.so with our own. Which is fine as long as it's actually being loaded. -- dwmw2 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: libnsssysinit
On 12/04/2014 02:00 PM, David Woodhouse wrote: On Thu, 2014-12-04 at 10:33 -0800, Robert Relyea wrote: 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. Huh? that is not true. libnssckbi.so is loaded by nssysinit, or by the application or by someone explicitly loading it into the pkcs11.txt/secmod.db. It is not loaded automatically by every nss application. OK... but applications such as firefox which actually want trust to work should be loading it, right? firefox loads libnssckbi.so only if not other 'Root Certs Module' has been loaded. the pk11-kit module is a Root Certs Module, so if it's been loaded, then libnssckbi.so isn't. Yes, there are some applications which use NSS only for private crypto purposes and don't need the trust roots, but Patrik seemed to be suggesting that in RHEL, even Firefox wasn't loading libnssckbi.so until he manually added it to pkcs11.txt/secmod.db. I believe the p11-kit does some magic to get it loaded for mozilla and the root store. Kai worked with stef to get that working, kai do you recall how that hooks in? I thought we really were just replacing libnssckbi.so with our own. Which is fine as long as it's actually being loaded. Sort of, It's not the same name, it's a different module, but it has the same attributes. bob 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
Re: Problems with Certificate Manager in Thunderbird using S/MIME
Haven't tested yet, but you could file a bug, altough I dont know if it will be accepted. If you have both accounts on your profile, you are the 2 people, hence there's no reason to send you a crypted message to yourself. I would accept the bug, but will give a 0.001 priority... A workaround could be creating 2 thunderbird profiles (ie: thunderbird -P) and configuring one account on each. Regards On Sat, Nov 15, 2014 at 5:19 AM, Serj ra...@yandex.com wrote: Hi, I have two email accounts in Thunderbird. I want to test S/MIME and send an encrypted message. I have a problem with Certificate Manager. When I have installed 2 email certificates for both accounts, after that I can't import a certificate into People tab of Certificate Manager - nothing happens, certificates aren't added. So, if there is no certificate(with public key) of recipient in People tab, Thunderbird can't encrypt the email message. Although it can digitally sign the email because for this operation we need only our own(for this email account) private key of certificate but not public key of recipient. Screenshot of the error during sending is attached: screenshot of the error during sending the email -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
