Hi again,
Thanks for all the info guys, it certainly answered some of my questions
(and I've also figured out some stuff while digging on my own).
With that being said, this still seems like a *huge* jungle for a
sysadmin, and while the introduction of p11-kit seems promising I'm
still somewhat confused.
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 ?
- We put out CA in '/etc/pki/ca-trust/source/anchors/', and import
'/usr/lib64/libnssckbi.so' into our 'sql:/etc/pki/nssdb'. Everything
works as I expect, great! But how is libnssckbi.so relevant to
'/etc/pki/ca-trust/source/anchors/' and/or to p11-kit. 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 ?).
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'
"Have all kinds of make us of our pkcs11-module if requested."
Seems to work with just (as long as the "all kinds of applications is
evolution/ff/chrome),
1) Make sure that '~/.pki/nssdb/pkcs11.txt' contains the lines,
library=/usr/lib64/pkcs11/opensc-pkcs11.so
name=OpenSC PKCS #11 Module
2) Make sure that ~/{.mozilla,.thunderbird}/*/*.default/ contains the
same lines as above.
Step 1 and 2, is made sure by checking this at user-login.
I've decided to remove 'opensc-pkcs11.so' from 'sql://etc/pki/nssdb'
since it's not needed there. Only reason I had it there was because I
thought that 'pam_pkcs11' needed it, but it turns out that 'pam_pkcs11'
will load the specified module from 'pam_pkcs11.conf' directly instead
of through the 'nssdb'.
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 ?
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".
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 ?
Edit2:
We now have a 'nss.sh' under '/etc/profile.d/' that exports
NSS_DEFAULT_DB_TYPE=sql.
Best regards,
Patrik Martinsson,
Sweden
On Tue, 2014-12-02 at 17:25 +0000, David Woodhouse wrote:
> On Tue, 2014-12-02 at 12:00 -0500, Miloslav Trmač wrote:
> > > Great. So that should solve Patrik's CA issues without needing to do
> > > anything special. All that remains is to get the smartcards working by
> > > loading p11-kit-proxy.so (or preferably the individual modules) too.
> > >
> > > Is that something we could do in the p11-kit-trust implementation of
> > > libnssckbi.so without having to add another hook?
> >
> > That feels like an pretty icky workaround, but I don’t actually know
> > whether it would or wouldn’t work. Stef, could the RHEL 6.5
> > p11-kit{,-trust} be (ab)used to load a smartcard token into all NSS
> > users (without changing the application-specific NSS configuration)?
>
> Well, the first question to ask would be about doing it upstream.
>
> Whether it can be backported to RHEL is a separate question for product
> management. (Individual users can of course do their own thing).
>
> I agree that it's a pretty icky workaround, but then again so is the
> current practice of simply *replacing* NSS's own implementation of
> libnssckbi.so with our own. But it's a neat trick which happens to work
> fairly nicely, and if we can extend it to *also* get the p11-kit
> configured modules to load at the same time without having to come up
> with further hacks, that would be quite nice.
>
> It also puts us in a good position to deal with the recursion that would
> otherwise happen when we attempt to put sql:$HOME/pki/nssdb into the
> user's p11-kit configuration. Doing that *and* manually configuring
> p11-kit-proxy into the NSS stack doesn't end well at the moment, but it
> should hopefully be simple to eliminate the duplicate if we do it this
> way.
>
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
