Just a quick update on my progress. The patch did fix my issue presenting the certificate to the server; thanks again. I'm now to find out why the ASA rejects my certificate when I connect with Openclient. %ASA-3-717009: Certificate validation failed. Reason: reason_string. A certificate validation failed, which might be caused by a validation attempt of a revoked certificate, invalid certificate attributes, or configuration issues. ? reason_string?The reason that the certificate validation failed 717009 Certificate validation failed. No suitable trustpoints found to validate certificate serial number: 134F02, subject name: cn=MCCLELLAND.MICHAEL.BLAIR.1250312705,ou=CONTRACTOR,ou=PKI,ou=DoD,o=U.S. Government,c=US, issuer name: cn=DOD EMAIL CA-30,ou=PKI,ou=DoD,o=U.S. Government,c=US .3 717027 Certificate chain failed validation. No suitable trustpoint was found to validate chain. Did a quick test from windows with the cisco client just to make sure my certificate itself wasn't the problem. I'm going to pull logs from a successful login and a failed one to compare. Thank you again for everything V/R MM -----Original Message----- From: David Woodhouse [mailto:dwmw2 at infradead.org] Sent: Thursday, July 12, 2012 11:51 AM To: Mcclelland, Michael B Mr CTR USN USA Cc: openconnect-devel at lists.infradead.org Subject: Re: CAC modules On Thu, 2012-07-12 at 10:54 -0400, Mcclelland, Michael B wrote: > Trying to get over the last hill but I'm coming up short. I've tried > multiple combinations of syntax but what I'm inputting doesn't seem to > work. I'll retry the Ubuntu build based on your suggestions as soon > as possible I'm just tunnel vision on Fedora since I'm so close. > > openconnect -c 'pkcs11:id=%00%01;object=CAC%20ID%20Certificate;' > https://testtesttest.test I think I *might* have fixed this in the 4.05 release. There's a Fedora 17 build at http://koji.fedoraproject.org/koji/taskinfo?taskID=4236846 or you can build from source. I now have a hardware token that I can test with, and it doesn't even let you *list* the private key if you're not logged in. The certificate (;object-type=cert) can be seen, but the corresponding private key (;object-type=private) isn't visible unless you've logged in to the token with the PIN. You can't even tell it's *there*. If your key shows up with 'p11tool --list-privkeys --login' but not with just 'p11tool --list-privkeys', that may well explain it. So when you *only* specify the object ID/name, and don't specify which *token* as well, the system doesn't actually know which token to find it in. And it won't go logging in to *every* token on the system, just to find out if it magically shows up in the list after doing so. So you might try providing the *full* PKCS#11 URL that p11tool showed you (without the ;object-type= part). It needs to include at least the token= part. *AND* you need to update to OpenConnect 4.05 because before that, OpenConnect would helpfully *strip* the part of the URL which specified which token to look in, before trying to load it :) So update to 4.05, then try: openconnect -c pkcs11:token=MCCLELLAND.MICHAEL.BLAIR.1250312;id=%00%01;object=CAC%20ID%20Certificate' $YOURSERVER (You can try connecting to random HTTPS web sites while you're testing, if it was actually your *VPN* account which ended up being locked out, not the hardware token itself.) -- dwmw2
