CAC modules

[Mcclelland, Michael B Mr CTR USN USA]

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