On Thu, 2014-12-04 at 12:26 +0000, David Woodhouse wrote: > > Note that the *labels* (the object= part) are different. Which is a bit > bloody stupid, but there you go. You're overspecifying, and that's why > it's not finding the certificate. > > Just drop the ;object=KEY%20%AUTH%20key part. And in fact you can drop a > bunch of other redundant stuff too. Just use something simple like: > > -c 'pkcs11:manufacturer=piv_II;id=%01' > > ... and that should be sufficient to identify *both* the certificate and > the key. I've just committed a patch which fixes this up a little to make it a little more user-friendly. Even if you specify the certificate by its label (object=xxx), where the label *differs* from the label on the key, we'll now attempt to cope with that. When all else fails, we'll forget the label you specified and look for a key with a CKA_ID which matches the ID of the cert that we *did* find. Thus, this should now work: openconnect -c 'pkcs11:object=Certificate%20for%20PIV%20Authentication' $SERVER And you can even cut and paste the full PKCS#11 URI of the *cert* from p11tool output and use it: openconnect -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=108421384210c3f5;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%01;object=Certificate%20for%20PIV%20Authentication;object-type=cert' $SERVER What you were doing, however, was using the label of the *key*. We look for the cert first and *then* try to find a matching key, so that won't work. Not without jumping through considerable extra hoops. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20141204/96d8591c/attachment.bin>
