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. -- 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
