IKE peer CRL check failed (0x00003618) – 3 fixes

30-Second Fix: Restart the IPsec service and flush CRL cache

This isn't the permanent fix, but it gets you connected right now. What's happening here is the IKEEXT service has stale or corrupted CRL data in its cache. The error 0x00003618 means Windows performed a revocation check on the peer's certificate, the CRL download or validation failed, and IKE refused to establish the connection.

1. Open Command Prompt as Administrator (Win+X -> Terminal (Admin)).
2. Run these commands in order:

   net stop IKEEXT
   net start IKEEXT
   certutil -CRL
   certutil -viewstore -enterprise Root

3. Try your VPN connection again.

The certutil -CRL command forces Windows to download fresh CRLs for all trusted root certificates. This often clears the failure if the problem was a one-time network glitch during CRL download. If the error returns after a reboot, move to the next fix.

5-Minute Fix: Disable CRL checking for IKE (registry tweak)

The real cause is that Windows's IKE subsystem is too strict. By default, IKEEXT checks CRLs for every certificate in the chain. If your VPN server's CA doesn't publish a CRL, or the CRL distribution point is unreachable from your network, you get 0x00003618. Microsoft gave us a registry key to relax this—without disabling CRL checking for everything.

1. Open Registry Editor (regedit) as Administrator.
2. Navigate to:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters

3. Create a new DWORD (32-bit) called DisableCRLCheck.
4. Set its value to 1.
5. Reboot the machine.

Setting DisableCRLCheck=1 tells the IKE service to skip CRL verification for all IPsec connections. This is safe for most corporate VPNs because the server certificate is usually trusted via a private CA. The downside? If someone compromises the CA and issues a rogue cert, your machine won't catch it during IKE negotiation. But for 99% of users, this fix is the correct one.

Advanced Fix (15+ minutes): Bypass CRL via Group Policy or certificate template

Maybe you can't edit the registry (locked down workplace laptop) or you want a surgical fix that only disables CRL checking for the specific server. Two approaches here. Pick the one that fits your environment.

Option A: Group Policy – Turn off CRL checking for IKE

1. Run gpedit.msc.
2. Navigate to Computer Configuration > Administrative Templates > Windows Components > IKE (on Windows 10/11 20H2+, it's under Network > IKE).
3. Double-click Turn off IKE CRL checking.
4. Set it to Enabled.
5. Run gpupdate /force and reboot.

This does the same as the registry key above but through Active Directory policy. On a domain-joined machine, this is the clean way.

Option B: Install the CA's certificate with the CRL distribution point disabled

If you control the VPN server's certificate, you can issue a new one without a CRL distribution point (CDP). Open your CA's Certificate Templates console, duplicate the template used by the VPN server, and on the Extensions tab, remove the CRL Distribution Point extension. Re-issue the server cert. When Windows sees no CDP in the certificate, it skips CRL checking for that specific cert. This is the cleanest fix because it doesn't weaken global security.

Why step 3 works

The reason Option B is superior: the 0x00003618 error occurs because Windows finds a CDP in the peer's certificate, tries to fetch the CRL, and fails (usually due to timeout or firewall blocking port 389 or 80). If there's no CDP, Windows doesn't even attempt the check. No attempt means no failure.

If you're on a home VPN (like a WireGuard or OpenVPN server behind a Fritz!Box or UDM Pro), the 5-minute registry fix is fine. If you're troubleshooting for a client or enterprise, go with Option B. It's the least intrusive.

One last thing: If none of these work, check if the VPN server's certificate has expired. Run certutil -store -user My and look at the NotAfter date. I've seen admins spend hours on CRL settings when the server cert had expired three months ago.