Certificate Auth not validating client has private key

[cam3]

Hi All.

Our goal is to ensure the AnyConnect VPN is only able to be used by corporate devices. 

Our expectation is that we can use Group Policy (or similar) to push a certificate to all computers that connect to the VPN, and this certificate is validated by the ASA.

We desire the certificate to be non-exportable so that it cant be used on another computer. 

We create our internal certificates using XCA (Like OpenSSL) and have an internal CA and intermediate CA already configured.

Using XCA I have created a CA, an Intermediate CA, and a 'client' certificate.

On the ASA I have installed the client cert and the CA's

And on the SSL settings I have configured the outside interface to use this identity certificate

And I have installed the client certificate onto the test computer

Now when I connect using the new VPN Profile I have created, it prompts me for the certificate, and it connects succesfully. 

If I select a random certificate, it does not connect. As expected

The problem is such: using windows certificate manager I can export the certificate off the computer without the private key. and this exported (keyless) certificate can then be installed on another computer and still connects

It seems the ASA is not validating that the private key is present in the client computer. 

I suspect this is something to do with the Certificate Matching or Certificate Pinning or something in the AnyConnect Client Profile but I cant seem to get it to work. 

This guide has been pretty helpful

https://www.cisco.com/c/en/us/support/docs/security-vpn/public-key-infrastructure-pki/200339-Configure-ASA-SSL-Digital-Certificate-I.html#anc18

But it even in this guide it shows screenshots of the client certificate without any private key. 

Can someone point me in the right direction for validating the private key on the client? Cheers! 

[Mohammed al Baqari · Accepted solution]

Hi,

The private key won't be validated by ASA and that is the concept of PKI.
In certificate authentication for VPN, the certificate it used for
authentication only. Technically, this means that the certificate will be
signed by the private key of the CA. When this certificate is sent to ASA
during key authentication phase, ASA will verify the signature of the
certificate by the CA using the CA Public key that is imported in ASA with
CA certificate. Once this is completed, the negotiation goes to next step.

Some implementations of certificate authentication have the client sign
message using its private key which should be validated by server (such as
ASA) using client's public key but this isn't the case in ASA AnyConnect
implementation.

The issue you are facing is a known problem hence they are external servers
used in authorization such as ISE to ensure that even if password or
certificate is stolen, you can still verify the connecting party.

certificate matching and pinning is something else used for auto tunnel
group selection and has nothing to do with exporting the certificate and
using it in different machine.

[carlmor2]

Do you know if this is still true for the current FMC/FTD versions?

[marie-flanagan]

Hi,
We got the issue sorted. I tried it on a fresh laptop and failed to connect as the cert validation failed. So, it seems that even though I had deleted the certificate on the test laptops, the private key remained in the store.
In short, the certificate validation is working as it should.

[Lukinno]

Hello, I believe that this is still true, atleast for latest version of ASA, as Im running one with exactly same issue (version 9.20(3)13).

Im not sure where the truth is, one say that this is how PKI should work, other one says that you always need a private key for authentication... Very hard to see where the truth is, but I believe that authentication should be always backed up by private key...

Just imagine a situation where you have PKI deployed, you have certificate issued by corporate CA, where you use one single certificate for SMIME email signature and for VPN authentication as well. You sign an email (and attach your public key), than user who received your email can just download your attached public key and succesfully authenticate against a VPN server.

This sounds just too crazy for me, and at this point, certificate authentication (without second factor like username / password) implementated by cisco is just unusable in my eyes. Any other opinion?

[mgrzesia]

Hi,

I think you were hitting bug CSCvg40155.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvg40155

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180418-asa1

If certificate authentication is used for VPN, the user needs to hold the private key, no excuses.

[marie-flanagan]

hello, I want to implement cert authentication + AAA.  In testing I have found that it works on a laptop with Cert + Private key installed, but it also works with just the cert (no private key).  This cannot be correct.

We are using Firepower 3100 running Cisco Adaptive Security Appliance Software Version 9.18(3)56

Can anyone advise?

thank you for any help!

[tvotna]

@marie-flanagan, yeah, I was able to connect too, although it was a quick test by exporting certificate without private key, removing certificate, installing exported certificate (without private key) and connecting. If you see this behavior by importing certificate without the key to *another* client PC, you need to contact PSIRT by email via psirt@cisco.com and also open TAC case if you have support contract.

[tvotna]

I'd also like to add that this behavior is unexpected. AnyConnect sends client certificate in both TLS1.2 handshake and within the application protocol. When it is sent in TLS1.2 handshake, Certificate Verify is also sent, which in my understanding requires private key.

Few AnyConnect TCP connections, which constitute tunnel establishment, contain dummy zero-size client Certificate and in this case Certificate Verify is not sent, but in my opinion there should be one with the real client certificate and in this case Certificate Verify must be sent in the same TCP segment or the next one. You can collect capture on ASA and verify.

[marie-flanagan]

thank you!  I've a call logged with TAC so we'll see what they say.

[tvotna]

What did TAC say?

[marie-flanagan]

TAC have been asking for info, screen shots, DART, show tech, etc.  No answer as of yet!