AnyConnect "Certificate Validation Failure" — and why the fix is rarely on your machine

“Certificate Validation Failure” means AnyConnect was offered a certificate by the VPN gateway and decided not to trust it. That is the client behaving correctly. In most cases the problem is on the gateway, and the advice to click through the warning is the worst thing you can do.

A certificate warning on a VPN is the one place you should be least willing to ignore it. The whole point of the tunnel is that you can trust the endpoint. If validation fails, you cannot — at least not until you know why.

The five real causes

In rough order of how often we see them:

1. The gateway certificate expired. Boring and extremely common. Everyone in the organisation loses VPN access at the same moment. If colleagues are also affected, stop and report it — there is nothing to fix on your machine.
2. Incomplete chain on the gateway. The gateway presents its own certificate but not the intermediate that links it to a trusted root. Browsers often paper over this by fetching the missing intermediate; AnyConnect does not. Classic tell: the VPN portal loads fine in a browser but the client refuses.
3. Hostname mismatch. You connect to vpn.company.com but the certificate was issued for asa01.company.local. Frequently appears after a gateway migration or a DNS change.
4. SSL inspection in the path. Corporate proxies, some consumer security suites, and hotel captive portals re-sign traffic with their own CA. AnyConnect sees a substituted certificate — which is, correctly, indistinguishable from an interception attempt.
5. Missing root CA on your machine. If your organisation runs a private CA, its root must be in your Trusted Root store. Fresh builds and personal devices frequently lack it.

The Windows-specific cause almost nobody explains

There is a genuine standards mismatch that produces this error on Windows even when every certificate is valid.

Checking revocation — whether a certificate has been cancelled early — is done with OCSP. Windows implements RFC 5019, the lightweight OCSP profile. Older Cisco ASA firmware implements RFC 2560, the original specification. The two differ in how nonces and request formatting are handled, and when Windows sends a request the ASA cannot parse, revocation checking fails — which the client reports as certificate validation failure.

How to recognise it:

• The certificate is in date and the chain is complete.
• The same gateway works from macOS or a phone.
• It began after a Windows update, not a certificate change.

The real fix is ASA firmware, which is your network team's call. Do not disable revocation checking on your own machine as a workaround — it removes the ability to detect a stolen certificate, and it hides the problem from the people who can fix it properly.

Two minutes of triage before you escalate

Answer these and you will know whose problem it is:

1. Is anyone else affected? Yes → gateway-side. Stop here and report it.
2. Does it work on another network? Tether to your phone. Works on mobile but not on the office or hotel network → SSL inspection in the path.
3. What does the browser say? Open https://<your-vpn-hostname> and inspect the certificate. Check the expiry date, the issued-to name against the hostname you type, and whether the chain shows an intermediate.
4. Did anything change on your machine? A Windows update, a new security suite, or a corporate device-management change immediately beforehand is a strong hint.

What you can legitimately fix yourself

Only two of the five causes are yours:

Missing root CA. If your organisation uses a private CA, obtain the root certificate from your IT team through a channel you trust — never from a link in an email — and install it:

certutil -addstore -f "ROOT" company-root-ca.cer

Interfering local software. If a consumer security suite has HTTPS or SSL scanning enabled, exclude your VPN hostname from it. This is a configuration change in that product, not something to solve by uninstalling your antivirus.

Everything else — expiry, chains, hostname mismatches, ASA firmware — belongs to whoever runs the gateway. If that is not clearly anyone at your organisation, that gap is the actual problem worth solving; our managed IT services cover exactly this kind of ownership.

What not to do

• Do not tick “connect anyway” if your client offers it. You are accepting an unverified endpoint for all your traffic.
• Do not disable revocation checking to make the message go away.
• Do not install a root certificate someone sent you, unless you can confirm through a separate channel that it is genuinely from your IT team. This is a standard phishing technique.
• Do not set your clock back. An expired certificate will validate again, and you will have broken authentication everywhere else on the machine.