On Wed, 2016-09-28 at 16:40 -0400, Sean wrote: > Hello, > > I'm new to the list and have looked back at 6 or so months of archives > for threads looking like they deal with smart cards and not discovered > what I'm looking for.??Please forgive me if this is answered and I > missed it, I'll happily take the link! > > I'm working to enable linux clients - who use pam_pkcs11, esc, > coolkey, etc. to log into their workstations with smart cards to be > able to connect to a smart card enabled Cisco VPN.??We're using > SCR3310 readers (mostly) already have the browsers using libcoolkey to access smartcard enabled intranet sites like Outlook Web Access on > these clients.??The smart cards are generated completely internally, > so when I use p11tool there is no manufacturer or model, there is only > URL, Label and Type fields populated.??The certificates are all signed > by an internal authority. > > Here's a small part of the token list: > > $ p11tool --list-tokens > Token 0: > URL: pkcs11:model=p11-kit- > trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust > Label: System Trust > Type: Trust module > Manufacturer: PKCS#11 Kit > Model: p11-kit-trust > Serial: 1 > > Token 1: > URL: pkcs11:model=p11-kit- > trust;manufacturer=PKCS%2311%20Kit;serial=1;token=Default%20Trust > Label: Default Trust > Type: Trust module > Manufacturer: PKCS#11 Kit > Model: p11-kit-trust > Serial: 1 > > Token 2: > URL: pkcs11:model=;manufacturer=;serial=;token=<my token name> > Label: <my token name> > Type: Hardware token > Manufacturer: > Model: > Serial: > > The rest of the tokens are from Gnome Keyring > > Here's what I've tried: > > $ openconnect -c 'pkcs11:model=;manufacturer=;serial=;token=<my token > name>' vpn.example.com > POST https://vpn.example.com/ > Attempting to connect to server 192.168.1.251:443 > PIN required for <my token name> > Enter PIN: <XXXXXX> > Error loading certificate from PKCS#11: The requested data were not > available > Loading certificate failed. Aborting. > > I have also tried the same command with > --cafile=/etc/pki/nssdb/cert8.db set since the client system as a > whole already has the CAs integrated into the nssdb.? You are conflating the two certificates. There's your own *client* certificate, which matches the key on the token. And there's the *server's* certificate, which it presents on the wire, and which you need to validate against the organisation's CA. Let's deal with the latter first: DO NOT put them in any NSS database. Just install them into the system-wide trust database (using update-ca- trust on Fedora), and then *all* applications will trust them ? regardless of whether they're using OpenSSL, GnuTLS or NSS. You shouldn't be messing around with installing them into various per- user and per-application NSS databases. Just fix it *once* with universal coverage. Also, if *any* application shipped by the distribution doesn't automatically use the coolkey module when it's installed correctly in the system, then that's a bug too. You could never have to install it specifically for any application; it should Just Work. Now, back to your initial problem... we haven't got round to validating the server's certificate yet; the above error is complaining that it couldn't find your *client* certificate. Is it actually in the PKCS#11 token? It doesn't have to be; perhaps only the *key* is in the token, and your certificate is somewhere else like in the NSSdb too? Can you show the output of ?p11-tool --list-all --login pkcs11:token=<your token> I note you haven't specified the certificate in the above command; only the *token*. Which sometimes might with if there *is* only one cert in the token, but you'd do better to actually specify the *certificate*. See http://www.infradead.org/openconnect/pkcs11.html?for some documentation on finding the URI for the certificate in the token. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20160928/3cc26b31/attachment.bin>
