I'm using Cisco AnyConnect Secure Mobility Client version 4.3.02039 on Windows 10.
When I try to connect to a specific VPN from my computer it fails:
Establishing VPN - Initiating connection...
Disconnect in progress, please wait...
The certificate on the secure gateway is invalid. A VPN connection will not be established.
AnyConnect was not able to establish a connection to the specified secure gateway. Please try connecting again.
Ready to connect.
Connecting to other VPNs is fine:
Establishing VPN - Initiating connection...
Establishing VPN - Examining system...
Establishing VPN - Activating VPN adapter...
Establishing VPN - Configuring system...
I've connected to the same VPN using the same credentials from 2 other machines just fine (from the same location).
So if it was an ASA or router issue one would think that wouldn't work.
If it was an EKU issue one would think that wouldn't work.
I've connected to the same VPN using the same credentials from within a VM on my computer.
I've had the administrator generate a new self signed cert on his side, with no change.
I've compared running services with another computer that works.
I've turned off the windows firewall and run vpnui as administrator, with no change.
I've uninstalled, rebooted, and reinstalled AnyConnect, with no change.
What can I do to knock my computer into working order?
I have "Bock connections to untrusted servers" unchecked.
When connecting I get the "untrusted" warning.
After entering my credentials I know that I get a second "untrusted cert" message on other machines.
I am not certain that I ever got that message on my computer.
Is there a location that I need to tweak something so it will prompt [again]?
I've searched the forums and found lot's of things that look close, but nothing has worked.
It would appear there's something amiss in your local certificate store. Assuming a Windows OS, I'd browse through certmgr.msc and see if anything rings a bell.
You could supplement that with a packet capture done during an unsuccessful connection attempt to see exactly which certificate exchange is failing.
I am on Windows (for better or for worse).
I don't see anything in Cert Manager for the good or bad connections.
I captured a good and a bad connection. Obviously the certificate names are different, but I don't see anything jumping out at me (though I'm not an expert). Of course the bad connection has a shorter conversation.
Both have a Server Hello, Certificate followed by some Cipher Spec Handshakes with some Application Data mixed in. The good connection ends with some Version Negotiation. The bad one does have some "Application Data[TCP segment of a reassembled PDU]" which the good connection does not have.
I am able to view the certificate from the web page. I saved it and imported it into my Personal and Trusted Root and my local machine Personal and Trusted Root. That didn't change anything though. The good connection cert has the same "This CA Root certificate is not trusted because it is not in the Trusted Root Certification Authorities store." message when I view the cert.
Now that I added the "bad" connection cert it reports as "OK", but the connection still gives the same error.
The good connection's cert has the IP, and it doesn't complain when you connect. The bad connection's cert has a name and complains that the "Certificate does not match the server name. Certificate is from an untrusted source."
I appreciate the pointers so far, any further pointers I should dig into?
I assume you're using the AnyConnect client directly.
What do you see if you instead browse to the ASA via the web portal using your browser and then open up the certificate for inspection using the browser tools? (View certificate, details and check the Subject CN or Common Name)
I also wonder if perhaps your VPN profile has an obsolete gateway FQDN that has somehow failed to get updated. (less likely but possible)
Oh boy, this is embarrassing. Nobody ever would have assumed to point me to the culprit.
In looking at the certificates and seeing that they used different algorithms it got me thinking that I should check what I have enabled.
Back in the days of Poodle I had run the Nartac crypto tool to turn off certain things (SSL, etc). So I downloaded the latest version, hit Best Practices, applied and rebooted.
Now it works just fine. So I shot myself in the foot by turning something off that didn't matter until I needed to connect to this new device.
I wish I took before and after screenshots so I could see what I had screwed up.
I doubt anyone else will run into that issue, but I certainly hope this saves them a few days of monkey business if they do.
Thank you very much for your time.
I changed the title to solved, but I'm not sure how to set the question status to "Answered".
You're welcome. thanks for updating us on the resolution.
I actually do something similar with our office ASA. In an effort to be a poster boy for best practices re lockdown (after all we sell my services), I have my SSL algorithms set to only accept strong crypto.
Unfortunately every time Java updates (at least once a month), it writes a new folder with its own /lib/security. I then need to go in and manually replace the default Java local_policy and US_export_policy jar files with the JCE (Java Cryptographic Extensions) ones. Otherwise ASDM is no longer accessible.
As Marvin is saying this looks like a certificate chain issue, now you can check the certificate you are attempting to use trying a connection using a browser and opening the certificate that is being presented when trying the connection, also there is a know issue on version 9.4 where even if you have the right certificate applied to the outside interface the connection is always going to attempt to use a default selfsigned certificate.
Hope this info helps!!
Rate if helps you!!
I ran into this today.
For my case, the user had an old version of anyconnect running (3.1). Once I installed the proper version (4.8), it worked fine.