On Mon, 2014-12-08 at 10:15 +0000, Martinsson Patrik wrote: > So, to summarize, > $> sudo update-alternatives --install /usr/lib64/libnssckbi.so > libnssckbi.so.x86_64 /usr/lib64/p11-kit-proxy.so 1000 > > $> cat /etc/pki/nssdb/pkcs11.txt > library=/usr/lib64/p11-kit-proxy.so > name=p11-kit-proxy > NSS=trustOrder=100
You shouldn't need that bit. It was only pam_pkcs11 which wasn't loading
the smartcard modules via the nssdb, and it wants to load OpenSC
*explicitly* anyway. And besides, *nothing* should be
using /etc/pki/nssdb since we can ditch the Shared System Database
nonsense. Just let use pam_pkcs11 use its default /etc/pam_pkcs11/nssdb
instead.
> $> rm -rf ~/.pki/nssdb/*
> $> rm -rf ~/.mozilla/firefox/*.default/{cert4*,key4*,pkcs11.txt}
> $> rm -rf ~/.local/share/keyrings
>
> Log out, log in again.
Are you logging in with password or smartcard?
You may be hitting a slightly unrelated issue with the GNOME keyring,
which is that it uses the system password to encrypt its own storage.
That's how it can support the 'protected authentication path' where the
PKCS#11 client doesn't actually need to *give* it a password — it's
already *got* one by stealing it from the PAM stack as you log in.
However, if you log in using pam_pkcs11 then GNOME keyring doesn't have
a password and can't unlock itself. So the first time it's used it's
*going* to ask for a password. Even in a well-behaved application like
Firefox which *can* support the protected auth path. And even when
you're using its non-PKCS#11 functions.
This is theoretically fixable — if you have the smartcard present for
login, GKR ought to be able to use *its* key for decrypting the storage.
(When authenticating with pam_winbind against Active Directory we have
similar issues for which we want to use the BackupKey Remote Protocol to
provide a key: https://bugzilla.samba.org/show_bug.cgi?id=9979 )
> And in my casse, *both* evolution and firefox asks me for,
> - First Password to my "Gnome2 Key Storage",
> - When entered, next dialog sows up, "Enter Password to unlock the
> certificate/Key storage" (and the option to automatically unlock it whenever
> I'm logged in"
> - When entered, next dialog pops up, "Enter the password for secret store"
>
> (screenshots attached).
>
> So basically, at least for me, none of the applications does the right
> thing,.
> Evolution prints the following when running from the terminal, "WARNING:
> gnome-keyring:: C_Initialize called twice for same process" which doesn't
> seem right.
You've loaded it twice. You didn't need to add it
to /etc/pki/nssdb/pkcs11.txt when everything *except* pam_pkcs11 was
already loading it for themselves.
>
> So, what we ended up with is two module-files under /etc/pkcs11/modules,
> $> cat gnome-keyring.module
> # The file is installed/loaded from the default module p11-kit directory
> module: gnome-keyring-pkcs11.so
> disable-in: evolution, google-chrome, firefox, thunderbird
If you fix the unlock-at-login issue then you shouldn't have to disable
this in any application for which there isn't already a "Does not
support Protected Authentication Path" bug filed. I.e. evolution.
> # And where to store and lookup trust objects
> x-trust-store:
> pkcs11:library-manufacturer=GNOME%20Keyring;serial=1:XDG:DEFAULT
> x-trust-lookup: pkcs11:library-manufacturer=GNOME%20Keyring
>
> $> cat opensc.module
> module:/usr/lib64/opensc-pkcs11.so
> enable-in: firefox, thunderbird, evolution, chrome, gnome-settings-daemon,
> modutil, seahorse
I'm not sure why you added that 'enable-in' line. This ought to have
been find in all applications, surely? Except pam_pkcs11 but see above.
--
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
