Fix ERROR_IPSEC_IKE_CRL_FAILED (0X000035F9) - VPN cert error

You're connecting to your company VPN and boom — the connection drops after a few seconds. You check the logs and see ERROR_IPSEC_IKE_CRL_FAILED (0X000035F9). This error hits most often when you're on a laptop that's been offline for a while, or when the VPN server's certificate authority (CA) is internal and your machine can't reach the CRL distribution point. I've seen this on Windows 10 21H2 and Windows 11 22H2, especially with Cisco AnyConnect and native IKEv2 VPNs.

Why does this happen?

The error is straightforward: Windows tried to validate the VPN server's certificate by checking its Certificate Revocation List (CRL), but the check failed. The CRL is a file hosted on a web server (often inside your corporate network) that lists certificates that have been revoked. If your machine can't download that file — because you're on a guest network, the server is down, or the URL is wrong — Windows panics and kills the VPN connection.

The default behavior in Windows is to fail closed: if it can't check the CRL, it assumes the cert is bad. That's what 0X000035F9 means.

The real fix (skip the registry)

Most guides tell you to mess with the registry to disable CRL checking. Don't do that — it weakens security for everything, not just the VPN. Instead, fix the CRL path or tell Windows to ignore CRL failures only for this connection. Here's how.

Check if the VPN server's cert has a valid CRL distribution point.
Open the VPN server's certificate in your browser or certmgr.msc. Look for the field CRL Distribution Points (CDP). It should list an HTTP or LDAP URL. If the URL is an internal address like http://corp-ca.company.local/certdata/crl.crl, your laptop needs to resolve that hostname and reach that server. If you're off the corporate network, you can't — and that's the problem.
Ask your network admin to publish the CRL to a public URL.
This is the cleanest fix: the CA can add an HTTP URL that's reachable from the internet (e.g., http://crl.company.com). Then your laptop will check that instead of the internal one. This takes five minutes for an admin and saves everyone headaches.
Add the internal CRL URL to your local hosts file (temporary workaround).
If the admin can't move fast, you can trick Windows by adding the internal CRL server's IP to your hosts file. But only do this if you know the IP is safe and you're on a trusted network.
```
# In C:\Windows\System32\drivers\etc\hosts, add:
192.168.1.100  crl.company.local
```
Replace the IP and hostname with your actual CRL server. This won't work if you're off the corporate network, though.
Disable CRL checking specifically for IKEv2 (advanced).
If you're using the native Windows VPN client (IKEv2), you can tell it to skip CRL checks without touching the global registry. Open PowerShell as admin and run:
```
Set-VpnConnection -Name "YourVPNName" -ServerCertificateValidation none
```
This tells the VPN client not to validate the server certificate at all. It's not ideal for high-security environments, but it beats being locked out. You can also use -ServerCertificateValidation RequiredCRL if you want strict checking, but that'll keep the error alive.
Update the VPN client (for third-party clients).
If you're using something like Cisco AnyConnect or Pulse Secure, update to the latest version. Older clients sometimes have their own CRL checking logic that ignores Windows settings. I've seen 0X000035F9 vanish after updating AnyConnect from 4.8 to 5.1.

What to check if it still fails

If you've tried those steps and still get the error, check these three things:

Date and time on your machine. If your system clock is off by more than five minutes, certificate validation fails before it even gets to CRL checks. Sync with time.windows.com.
The VPN server's certificate itself. Is it expired? If the server's cert is past its validity period, no CRL trick will help. Ask your admin to renew it.
Your antivirus or firewall. Some security suites (I'm looking at you, McAfee) intercept certificate validation and block CRL downloads. Try disabling the VPN-aware feature temporarily.

This error is frustrating because it's a false alarm — the server's certificate is usually fine, but Windows can't prove it. The steps above let you bypass that check safely. Skip the registry edits; they cause more problems than they solve.