Machine certificate not properly checked?

[navtom]

How does ASA verify that received machine certificate is valid? I would like to think these steps are followed:

1. Has the Digital Certificate been issued/signed by a Trusted CA?
2. Is the Certificate Expired – checks both the start and end dates
3. Has the Certificate been revoked? (Could be OCSP or CRL check)
4. Has the client provided proof of possession?

1) working for sure

2) working for sure

3) can not be done, CRL is not configured

4) can not be done, machine cert was installed without private key

Is that correct? Private key possession is not checked? That does not sound secure.

When I was setting up the VPN, one of the certs was not being sent to the ASA at all (some general error was produced at client's end). I had to TShoot this with TAC. The engineer noticed the private key was missing from the windows cert store and urged me to import the cert again with private key. So even TAC thinks the private key should be present. However the client connects fine without it.

Any thougts?

[Mohammed al Baqari]

The private key doesn't need to be there. Client VPN doesn't perform mutual
authentication. Its only client to server authentication using the
certificate. Therefore, if you export the cert and import in other machine
that still works.

The best practice is to use combination of AAA and Cert auth to validate
the machine and user identity but if you can implement measures on machines
that certificates can be exported and imported on other machines using
their party tools then it should be fine.

This is unlike l2l vpn using certificates which require private key at both
sides and perform mutual auth.

[navtom]

Greetings Mohammed,

you mention "Its only client to server authentication using the certificate." but without the private key we are unable to perform that in a trustworthy manner. At least as I see it.

Anyway why would TAC insist on having the PK imported when it is actually not needed. That kinda bothers me, because it prolonged the troubleshooting.

[Mohammed al Baqari]

That's true in the sense if an attacker manage to get the client
certificate then he can authenticate successfully.

The private key is used in l2l vpn but not anyconnect as I mentioned
earlier. Not sure why tac insisted on private key. You can ask them but
its not used in anyconnect definitely

[navtom]

I asked the TAC about it, and this is their response. It is possible, that TAC does not know how to process works. However I definitely need some official Cisco materials stating that the private key is not checked. Do you happen to know about some?

Hello,
You have mentioned that the new certificate is without a private key, so can you please either take a screenshot or send the whole certificate with the full chain.
Because the private key is used for decrypting the traffic, and I don’t believe that this should be working without it.
Now regarding the certificate validation, the AnyConnect solution validates the certificate the same way any SSL connection does.
To be honest I couldn’t find a document that specifies the validation and authentication process for AnyConnect but will check again.
I will be looking forward to hearing from you. 

[navtom]

Hello to all,

for anyone curious, I just received and explanation from TAC. The private key needs to be there. If it does not show the little golden key in the certificate detail window and you are still able to authenticate, you actually have the private key and buggy Windows are not showing it. It can be repaired with certutil.exe.

I did some tests and it seems to be working exactly as described by TAC.

To authenticate the AnyConnect client by the ASA, we use the TLS standard handshake and it’s not specifically something that the AnyConnect would change, with that being said the private key must be on the client machine for the authentication to work.

If the private key was missing we would see the below error on the ASA:
Description: unknown missing private key for client cert file: 

And on the client :
"Certificate validation failure"

[Shakti Kumar]

Hi navtom

Client will not be able to pick up a certificate unless it has a corresponding private key to it. This is more of a SSL feature rather than AnyConnect feature. Most likely the user machine picks up a different certificate issued by a different CA.

We can troubleshoot this further if you want let me know.

Thanks

Shakti

[navtom]

Hello Shakti,

according to "debug crypto ca 200", the client sends the exact certificate I have selected - the one without PK. I enabled the option where clients are able to select a certificate themselves.

Furthermore, I believe that if it was purely SSL solution, everything would depend on the server certificate. Which seems it does so far.

I do not need to troubleshoot it as much as I need to find an official Cisco document describing this process.