cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
210674
Views
10
Helpful
25
Replies

Cisco AnyConnect 3.0.08057 certificate validation failure

lastina38
Level 1
Level 1

Hi,

In order to let you know :

Does someone know if Cisco AnyConnect v3.0.08057 have a bug with certificate authentication ?

We have an ASA5520, IOS 8.4.3, and several tunnel-groups available. One of them use a certificate-based

authentication.

We are using Cisco AnyConnect v3.0.07059 without any problems with the tunnel-group using

certificate-based authentication.

However with the latest version of Cisco AnyConnect (v3.0.08057) it does'nt work. It seems AnyConnect

does'nt find a valid certificate for authentication. That's quite strange tbh.

And as I am under Windows 7, it's not possible to currently know where AnyConnect is really looking for certificates.

Did someone encounter a similar problem ?

Thanks.

Marc

25 Replies 25

Nicola Volpini
Level 1
Level 1

Hi Marc-Olivier,

I have the same issue here. It seems like there's a bug in that specific version. The bug is cross platform since it's present in the official linux client as well.

I started to experience this issue after the updated version of the client got automatically pushed via the ASA (I had previously updated the package on the appliance for all operating systems).

Ok. Thanks for confirmation.

I'm starting to think this is not exactly a bug, but a consequence of the new version enforcing some stricter checks. These release notes might be a clue:

http://www.cisco.com/en/US/customer/docs/security/vpn_client/anyconnect/anyconnect30/release/notes/anyconnect30rn.html#wp1577925

An extract from that link:

Changes to Server Certificate Verification

The following behavioral changes are being made to server certificate verification:

SSL  and IPSec connections from the AnyConnect client to the secure gateway  being performed using the FQDN of the secure gateway will no longer make  a secondary server certificate verification with the FQDN's resolved IP  address for name verification, if the initial verification using the  FQDN fails.

SSL  and IPSec connections from the AnyConnect client to the secure gateway  require server certificates to contain Key Usage attributes of Digital  Signature and Key Encipherment.

SSL  connections from the AnyConnect client to the secure gateway require  server certificates to contain an Enhanced Key Usage attribute of Server  Authentication.

You may be right ...

However, here (in your extract) we are speaking about the verification of the server certificate.

In my case, it "seems" it's more likely a client certificate error

The AnyConnect client says (or Windows logs in fact) : no valid certificate found for authentication.

In your link we can also read :

We strongly recommend you enable Strict Certificate Trust for the AnyConnect client for the following reasons : ...

... but I never did it.

Well at the moment we are staying with AnyConnect v3.0.07059, even if it's no more available

as a download from the Cisco website (they only let the latest version).

Good point. We'll run a few tests here to try to find the culprit. I'll keep you posted!

We have the same issue after upgrade to 3.0.08057..  Please let me know if there is any solution to this.

I have exactly the same issue and I use the local ca of the asa.

I noticed that the certificate issued to the user by the local asa does not have the Enhanced Key Usage attribute of Server Authentication in the certifiacte details. so it must be the local asa having the problem, is there a way to add this in the local ca of the asa

I'm pretty sure Cisco is reading this. I guess we can only hope for a Cisco tech to add some input to this discussion. Clearly, this is not an isolated case.

Also, I wanted to downgrade but, as stated by Marc-Olivier, there are no older 3.0.x versions available on the website.

found a soultion to this, you have to create a profile and in the certificate matching tab you must tick the the key usage were applied according to the certificate you have on the PC. disable the certifcate authetication on the connection profile, connect one time with aaa only so to get the new settings for the anyconnect, then put back the certificate authetication and it should work

Nicola Volpini
Level 1
Level 1

We succeeded to make it work, yet something is confusing me.


In our case, the problem exists in the client certificate.
We regenerated the client certificate to contain some of the values required by the new anyconnect version:

Key Usage attributes: Digital  Signature, Key Encipherment.

Enhanced Key Usage attributes: Client Authentication.

The attached image shows how the certificate looks on a Windows 7 client, and the two values are present:

As you can see, the Enhanced key is showing an OID value corresponding to the Client Authentication (1.3.6.1.5.5.7.3.2), while the server authentication OID is absent in this case (1.3.6.1.5.5.7.3.1). These informations have been found here:

http://www.cisco.com/en/US/tech/tk722/tk809/technologies_white_paper09186a008009256b.shtml#wp39121

Search in particular for the "5.2.2 AAA Server Certificate Requirements" section in that document, mentioning the EKU field.

It indeed works for us but still doesn't make sense, since the release notes are mentioning the Enhanced Key "Server Authentication" on the ASA side as a requirement, not the "Client Authentication" on the client side.

I'll try to provide more details.

Byron Jones
Level 1
Level 1

I've just got off the phone with Cisco and a very helpful guy called Herbet Baerten who assisted me in a work around for this as you've all identified it is a problem with the latest anyconnect using stricter checking and requiring a key usage field which is not generated (presently) on the LOCAL CA.

CSCua89091    the local CA needs to support EKU and other necessary attributes

CSCua89081    DOC: Anyconnect requires specific Extended Key Usage in client certs

To work round this under the anyconnect client profile in "Certificate Matching"  we added a Distinguished Name check in our case we matched "O" to the company name which was distributed in the client certificate.

Hi Byron,

Somehow I am stil having same issue after applying your work around on the ASA.  do you need to change anything on the client certificate site?

Thanks!

Lynn

Hi Lynn,

Did you ever get it to work? I'm having the same issue. I tried Certificate Matching, but didn't help. I'm not sure whatelse is missing.

Thanks,

Tao

Hi Tao,

No.. We did not get it work. Opened a case with Cisco, and the tech said,both server and client certificate needs to have EKU field.  I am going to wait for next release of anyconnect to test it out again.

Lynn

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: