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.
I'd be extremely grateful if anyone has any suggestions on what to try, before I goto TAC with this.
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.
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.
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?
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.
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....
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.
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?
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...
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?
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.
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.
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...
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.
It might well have been the reload that was necessary to upgrade (as opposed to the upgrade itself) that caused things to start working. I have seen other devices (Cisco ACE) require at least a warm reload when changing certificate-related parameters.
What was your old and what is the new version?
I'm not sure am allowed to state version usage publicly, but we have another ASA built the same as the other with the old version still running. When we come to migrate that (soon) I'll find out if it has the same issues, first do a warm reload and then upgrade version if it didn't work.
You're right on Marvin, On ASA ver 8.4 (2) I receive this same error "failed to update pki session with ikev2 trustpoint" after changing identity certs for Clientless SSL. It seems to yield this error regardless of the type of CA used, whether or not it includes the "server authenticatio" eku, as I was able to duplicate this behavior after issuing from a MS 2012 R2 CA and an IOS CA. After rebooting the ASA it's fine with the cert and everything works.
You're right on Marvin, On ASA ver 8.4 (2) I receive this same error "failed to update pki session with ikev2 trustpoint" after changing identity certs for Clientless SSL. It seems to yield this error regardless of the type of CA used, as I was able to duplicate this behavior after issuing from a MS 2012 R2 CA and an IOS CA. It also doesn't seem to matter whether the eku "Server Authentication" is there or not (at least for Clientless Remote Access). After rebooting the ASA it's fine with the newly selected cert and everything works.
I am labbing this so I can conclude what`s missing but I believe you are not enrolling correctly with the asa with the CA. Also, for Java applications such as any connect and the asdm you have to use a code certificate what means something is missing anyways. So far my any connect presents me with the correct trusted certificate. I`ll let u know when I am finished.
wow you guys are going to loads of trouble for this, thanks loads.
I'll have another look at enrolling: but doing it again yesterday it didn't moan about the enrollment when adding the CA certificate..
It`s no problem at all, I am also having certificate issues but concerns another area of expertise involving SCEP auto-enrollment. For some reason I think the problems are almost the same because when I authenticate using the new certificate it seems to be impossible to match the certificate properly and then it enrolls to a new certificate, it`s really giving me a hard time on solving it and I can`t find a way to match it. As per the certificate you are telling I am pretty sure it`s something related to the enrollment. When you enroll to this type of thing, you need to enroll in 3 different trust points for 3 different areas, the internal certificate, the SSL validation and the Code signer. The first is for the ASA itself, the second for the SSL vpn and the last for java applications such as any connect and ASDM. I am simulating, as soon as I get a proper conclusion I`ll let you know.
I've created quite a few certificates from various templates and have been trying with this for a while: when I change the certificate under the Anyconnect configuration, I can see from trying from a web browser that the certificate has changed.
Templates I've used are ipsec, computer, web server and as far as I'm aware, web server should just work with very little configuration...
Quite a few at the moment: testing between quite a few ID certificates, and two different PKI servers so there are a few trustpoints to choose from. When the client certificate is shown to the ASA by the anyconnect client, it is able to validate that certificate by a trustpoint.