ipsec ikev2 vpn microsoft CA problem

[sam mackenzie]

Hi guys

Have been searching for a few days now and not been able to find the answer to my issue.

I've been given requirements to create an IPSec Ikev2 vpn using internal microsoft PKI (not digicert etc, but corporate), with windows 7 clients, cisco anyconnect mobile client, to access internal resources from external networks.

So far it's all working except that the client does not accept the certificate for its intended purpose as you can see in the image below. 

The ID cert on the ASA has been installed from Microsoft PKI, and it has the root certificate installed on the ASA. 

The root certificate is also installed in the win7 client's trusted root certificate store for both user and machine.

The PKI root CA is windows server 2003.

The requirements for IKEv2 certificates fulfilled in the ID cert (digital sig, key encipher, EKU for server auth) and have even made a new template with ALL EKU values with no difference. 

I know a bit about certificates and have made sure that the root cert is installed in both the user store and machine store. 

There is no issue with trusting the chain as far as I can see since opening a web page to the ASA am able to see the certificate and the chain with no issues.

http://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect31/release/notes/anyconnect31rn.html#pgfId-43195

I'd be extremely grateful if anyone has any suggestions on what to try, before I goto TAC with this.

Cheers loads,

Sam

[auranprost]

Hi Sam,

It does not look like a EKU ou anything else. For me it looks like your machine does not know the root CA. Did you install the root CA certificate on the machine that you`re testing?

Are you using SCEP for the certificate enrollment on the machine or are you using manual certificate enrollment?

For this specific message to be gone you need to make your machine recognize your root CA as one of the trusted root CAs in the machine, which means you have to download and install the root CA certificate on the machine as well as the machine certificate or user certificate itself.

If you can, and I highly recommend you doing this, you can download the anyconnect Diagnostics and reporting tool (DART) to troubleshoot the certificate validation. If you make it and if you can put the package here so we can look at it together would be very nice to troubleshoot the certificate issue with you.

BR,

Bruno Silva.

[sam mackenzie]

Hi Bruno,

Thanks for your quick reply.

The machine has got the root CA cert installed in both the user and machine certificate stores in the trusted root stores.

This is the information I have also found, that the certificate is not being trusted: but going via a web browser to the ASA and viewing the ID cert via internet explorer shows the chain is valid and it looks like the machine is able to see the store and trust the root but something might be wrong with the mobility client?

Unfortunately I can't easily put together the dart package for public posting since it will contain information I am not able to post. I can sanitise a version but it could take a while.

[Marvin Rhoads]

You certainly seem to be looking at the right place in the AnyConnect Admin Guide.

When you examine the certificate in the browser, what purposes does it purport to be intended for?

[sam mackenzie]

Hi Marvin, it has "ensures the connectivity of a remote computer"

Thanks

[Marvin Rhoads]

I'm not sure if it's relevant but I just checked a working one that I have (GoDaddy certificate) and it "Ensures the identity of a remote computer".

Also - note that "From AnyConnect 3.1: if EKU or KU are present, they must be correct". See the Ciscolive365 presentation BRKSEC-2033, page 29.

[sam mackenzie]

Cheers Marvin, I'll check it out and make doubly sure that the EKU and KU are correct.

edit: whoops it is Identity on mine, must have been thinking of connectivity when typing....

[sam mackenzie]

The EKU and KU are definitely correct - have made sure.

KU - critical for digital signature and key encipherment, and EKU of Server Authentication.

Template used is WebServer.

Have run a DART and have found the part of the logs relating to the certificate error which are just after the connection is initiated - have attached to this post.

[auranprost]

Hi Sam,

Looking at your DART logging it looks like the certificate is not the proper certificate for what you are using. That`s quite awkward. Are you using SCEP for this?

[sam mackenzie]

Hi,

I'm manually creating the requests.

I know that's what it looks like: but I'm using microsoft windows 2003 PKI with the standard webserver template, and including digital signature, key encipherment and eku of server authentication. Do you think the purpose is not correct? I'm not sure what else to try here regarding the certificate - especially after trying a template with ALL EKU values possible to try...

[auranprost]

Hi Sam,

From what I am used to you should never use the standard templates to anything, what means that you should create a new template for this. Nevertheless, let me point your troubleshooting so far:

1 - Created the trust point;

2 - Enrolled to all certificated, user, ipsec and webserver

3 - Edited and changed KU and EKU fields (even though they should only be changed when you match the certificate field inside the XML file on the any connect before version 3)

4 - Enrolled to multiple trustpoints manually;

Now, let me go through your enrollment process on ASA:

1 - create the certificate on the asa (crypto key generate rsa)

2 - Created the trust point with your CA server (crypto ca trust point)

3 - Enrolled to the certificate

4 - Generated the certificate and installed it on the ASA (using the web server default template)

5 - Configured the any connect ikev2 parameters to use the certificate that was installed during the last process.

Is all of this correct?

[sam mackenzie]

Hi,

I've been using ASDM for this since it makes it easier to up/download requests certificates etc.

Firstly I installed a root certificate onto the ASA as a CA certificate, at the time choosing a name for a trust point, which it creates as part of the ca certificate import.

Next I go to my certificate server and create a certificate for the Identity for the ASA. I've done this several ways: using an existing template and making new ones - making private key exportable, importing the cert, exporting with private key, and uploading to ASA via ASDM including private key.

Once ID certificate installed on ASA then IKEv2 configured on the interface to use that certificate. 

[Marvin Rhoads]

I think I have a lab guide at home that recommends not using the default certificate templates. I'll try to find it and see what it suggests.

[sam mackenzie]

Hi,

am pretty sure it's nothing to do with the certificate now, have created both a self-signed certificate on the ASA and had the same message - as well as using certificate cervices on a different PKI with exactly the same error. 

There is an error the ASA is throwing up which we've just noticed when changing the IKEv2 trustpoint to use a different certificate:

when adding the command

crypto ikev2 remote-access trustpoint TRUSTPOINT_NAME

it responds with 

ERROR: Failed to update PKI session with IKEv2 trustpoint.

but does take the command. Currently trying to find out what that means and if it has any bearing but assuming not because when the Anyconnect client gets presented with the certificate it's the one moaning about the purpose not the ASA...

[sam mackenzie]

Guys - thanks for all your help: it is all working, but I don't understand how.

We upgraded our ASA software and everything started working. 

What I don't understand is the message on the client and the log files within the ASA: showed that the CLIENT was having a problem with the certificate: so we didn't think it was anything to do with the ASA software - how could it be?

Anyway, after an upgrade it's absolutely fine.

Thanks so much for all your help: Really appreciate the time you have spent on it.

Sam