We've been using the AnyConnect client (SSL/TLS) with an ASA 5520. The client needs to present a certificate to be authenticated. We're moving to a new certificate issuer for the client certificates.
This third-party certificate issuer uses RSA encryption and SHA256 hashing to sign the client certificates. That's not a problem. We use SHA256+RSA client certs on identical hardware and software for a different SSLVPN service.
However, the certificate of the issuer (the intermediate certificate authority) is signed using ECDSA encryption, not RSA. The exact error we get when AnyConnect presents one of these client certificates is "Certificate chain failed validation. Generic validation failure occurred." This is preceded immediately by "Certificate was successfully validated. Certificate is resident and trusted...," so the client certificate appears to be fine. I'm assuming the ASA just doesn't like the ECDSA-signed intermediate certificate.
Note that the root CA for the new issuer is also in place on the ASA, but it, too, uses ECDSA. We do not have CRL checking turned on.
As far as I can tell, ECDSA is not supported for use in TLS on the ASA until version 9.4. As far as I know, an old 5520 (not a 5525-X) will not run anything beyond 9.1.x.
Is there some way that I can make this work? We aren't concerned with verifying the chain to the root CA; we just want to verify that the client came from the issuer, and we know that the copy of the issuer's certificate on the ASA is good.
--Jeff
