Anyconnect Certificate Validation Failure after upgrade to 9.3.x/9.4

[crankymonkey1]

Hi all,

I've got an ASA5512-X, running 9.1.2, configured as a remote access VPN. I've configured it for aaa and certificate based authentication (Windows 2012 Certificate Server and radius authentication), using SCEP for trustpoint enrollment and OCSP for revocation checking as per this guide http://www.cisco.com/c/en/us/support/docs/security/adaptive-security-appliance-asa-software/116720-config-asa-ocsp-00.html

The remote clients are Linux Debian OS using Anyconnect Client version 4.0.00061. The Windows Cert Server has been configured to generate certificates using RSA 2048 SHA1. 

So far so good - everything is working as expected and remote devices can connect without issue.

As soon as I upgrade the ASA to 9.3.x or 9.4 no devices can connect and the Anyconnect Client displays the Certificate Validation Error message. 

The ASA logs show that AES256-SHA is selected as the cipher, the correct trustpoint is selected and the SSL handshake completes using TLSv1.2. However, the connection immediately terminates with a TCP Reset-I message.

I've run debug crypto ca 255, debug crypto ca messages 255 and debug crypto ca transactions 255 on 9.1.2 and 9.3.x/9.4 and the only difference is that the ASA doesn't try and validate the certificate using OCSP after the upgrade - it seems to completely ignore revocation checking. I can't see any other useful info in the logs.

I've also tried using certificates from a cert server built using RSA2048 SHA256 (to try and be tlsv1.2 compliant) but I get the same result - works on 9.1.2 but not on 9.3.x or 9.4. It still works with 9.2.x, so it seems that something might have changed between 9.2.x and 9.3.x

Any ideas?

Thanks,

CM

[rvarelac]

Hi CrankyMonkey, 

9.4 image includes new features for SSLTLS that might be impacting your certificate authentication. 

• "Elliptic curve cryptography for SSL/TLS—When an elliptic curve-capable SSL VPN client connects to the ASA, the elliptic curve cipher suite will be negotiated, and the ASA will present the SSL VPN client with an elliptic curve certificate, even when the corresponding interface has been configured with an RSA-based trustpoint. To avoid having the ASA present a self-signed SSL certificate, the administrator needs to remove the corresponding cipher suites using the ssl cipher command. For example, for an interface configured with an RSA trustpoint, the administrator can execute the following command so that only RSA based ciphers are negotiated"

As workaround you can try to use the following cipher configuration and check if works.

ssl cipher tlsv1.2 custom "AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:RC4-SHA" 

Reference link

http://www.cisco.com/c/en/us/td/docs/security/asa/asa94/release/notes/asarn94.html

Rate if helps.

-Randy

[crankymonkey1]

Hi Randy,

Thanks for the reply. I did see that but it didn't work unfortunately. I found that if I didn't include the tlsv1.2 command then the ASA presented its self signed certificate. Once I'd applied that line the ASA presented the correct certificate with the AES256-SHA cipher, but I still got the certificate validation error. I've also amended the tlsv1.2 config so that only 1 cipher is presented and tested each cipher individually, e.g.

ssl cipher tlsv1.2 custom "AES256-SHA", ssl cipher tlsv1.2 custom "AES128-SHA", etc.

I also saw another thread, https://supportforums.cisco.com/discussion/11533701/cisco-anyconnect-3008057-certificate-validation-failure, and have amended my certificates to include the following, but it still hasn't worked.

Key Usage attributes: Digital  Signature, Key Encipherment.

Enhanced Key Usage attributes: Client Authentication.

Totally stumped! Might be time for a TAC case.

Cheers,

CM

[Matthias Jeker]

Hi

For me the the workaround did fine:

ssl cipher tlsv1 custom "AES128-SHA:AES256-SHA:DES-CBC3-SHA"
ssl cipher tlsv1.1 custom "AES128-SHA:AES256-SHA:DES-CBC3-SHA"
ssl cipher tlsv1.2 custom "AES128-SHA:AES256-SHA:DES-CBC3-SHA"
ssl cipher dtlsv1 custom "AES128-SHA:AES256-SHA:DES-CBC3-SHA"

This is the SSL config which I use. Afterwards I removed the trustpoint from the interface and added it again. I disabled and then reenabled the webvpn.

Now the error was gone in the AnyConnect, IE and FF but not in Chrome. After a restart of chrome the ASA presented the correct certififacte and I was able to connect.

Customer uses an old AnyConnect version... anyconnect-win-3.0.08057-k9.pkg. Have you tried another AnyConnect version?

Regards

[edatwyler]

See Bug CSCus78450.  Looks like we'll need to remove all trustpoints and re-build them.  I will be doing this potentially this evening and will report the result.

[edatwyler]

Removing all trustpoints and related certificates worked for me.  I re-imported my on-premise CA root certificate and aaa/certificate VPN is working again.