Fixing ERROR_IPSEC_IKE_INVALID_SIGNATURE (0x00003602)

If you're seeing the ERROR_IPSEC_IKE_INVALID_SIGNATURE (0x00003602) error — and you're staring at an IPsec VPN that won't connect — I've been there. It's maddening because everything looks configured right but it still fails. The real cause is almost always a certificate trust issue or a time sync problem. Let's fix it.

The Fix: Rebuild Certificate Trust Chain

What's actually happening here is that the IKE (Internet Key Exchange) protocol on one side can't verify the digital signature presented by the other side. That signature is generated using a certificate's private key. If the receiving machine doesn't trust the issuing CA (Certificate Authority), or if the certificate chain is broken, you get this error.

The quickest fix: manually rebuild the trusted root certificate store on the machine acting as the VPN server (or the client, depending on your setup).

1. On the affected Windows machine, open an elevated PowerShell or Command Prompt (Run as Administrator).
2. Run certlm.msc (for local machine certificates). If you're on a domain controller, use certlm.msc too — not the user store.
3. Navigate to Trusted Root Certification Authorities > Certificates.
4. Look for the CA that issued the IPsec certificate. If it's missing or expired, import it. Export the root CA certificate from the issuing CA server (certlm.msc > Trusted Root > right-click > All Tasks > Export), then copy it over and import it here.
5. If the root is already there, check its expiration date. A expired root — even if the leaf cert is still valid — can cause this error. Windows doesn't always flag this clearly.
6. After importing or updating, run gpupdate /force (if the machine is domain-joined) and restart the IPsec services: net stop IKEEXT & net start IKEEXT.

The reason step 3 works is that IKEv2 and IPsec in Windows require a complete certificate chain from the leaf cert all the way to a trusted root. If any link is missing or invalid, the signature verification fails with 0x00003602. No workaround exists — the chain must be intact.

Why Time Sync Matters

If the certificate chain looks fine, check the system clock. Even a 5-minute drift between the two VPN endpoints will cause signature verification to fail. This is because certificates have a validity period (Not Before / Not After), and the IKE protocol checks the timestamp of the signature itself. If the receiver's clock is outside that window, it rejects the signature.

Fix: set both machines to sync with the same NTP source. On Windows:

w32tm /config /syncfromflags:manual /manualpeerlist:"pool.ntp.org"
w32tm /config /update
w32tm /resync

Then verify with w32tm /query /status. The offset should be under 1 second. If not, check firewall rules — NTP uses UDP port 123.

Less Common Variations of the Same Issue

Certificate Revocation List (CRL) Check Failing

Some strict IPsec policies enforce CRL checks. If the CRL distribution point (CDP) in the certificate is unreachable (e.g., no network path to the CA's web server), the IKE negotiation fails with this error. To test: browse to the CDP URL listed in the certificate's CRL Distribution Points extension. If it's offline, you have two options:

• Disable CRL checking for IPsec (not recommended for production, but valid for testing). Set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\AssumeUDPEncapsulationContextOnSendRule to 2 (DWORD).
• Better: reissue the certificate with a reachable CDP.

Certificate Not in the Machine Store

IPsec certificates must be in the Local Machine certificate store, not the current user store. If you imported it via certmgr.msc (user store), it won't be visible to IPsec. Move it to certlm.msc > Personal > Certificates. This is a common mistake on standalone servers.

Group Policy Override

If your organization uses Group Policy to push IPsec rules, a misconfigured policy can override local settings. Check Computer Configuration > Windows Settings > Security Settings > IPsec Policies in the GPMC. Look for rules that require a specific certificate that's not installed on the machine. The error here is usually the same — the IKE negotiation fails because the required cert isn't trusted.

Prevention

Once you've fixed it, you don't want this to come back. Here's what to do:

• Monitor certificate expiration dates. Set up a scheduled task or a simple PowerShell script to email you 30 days before a cert expires. Use Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.NotAfter -lt (Get-Date).AddDays(30) }
• Keep time sync consistent. On domain-joined machines, domain controllers should sync from a reliable external NTP source. Non-domain machines should explicitly point to the same NTP pool.
• Test CRL endpoints. If you control the CA, make sure the CDP URLs in the certificates point to something that won't go offline. For production IPsec, consider using robust internal CDP servers with redundancy.
• Document the certificate chain. Know which root, intermediate, and leaf certs are used for IPsec. A change in the CA hierarchy (like a root update) can break the chain without any obvious warning.

The 0x00003602 error is Windows's way of saying "I don't trust the other guy's credentials." Once you understand it's a trust/time/chain issue, you can solve it in 10 minutes. Don't waste time reinstalling the VPN role or rebuilding the server — that never fixes it.