Fix ERROR_IPSEC_IKE_PROCESS_ERR_SIG 0x0000360E

You're setting up an IKEv2 VPN connection on Windows 10 or 11. Everything looks good — server is running RRAS or strongSwan, certificates are installed. Then the connection fails with ERROR_IPSEC_IKE_PROCESS_ERR_SIG (0x0000360E).

What's actually happening here is the VPN client gets the server's certificate, but when it tries to verify the cryptographic signature on that certificate, it fails. The signature is the thing that proves the certificate is genuine and hasn't been tampered with. This isn't a network problem — it's a certificate trust chain problem.

Root cause

The signature payload is the digital stamp inside the IKEv2 authentication exchange. The client receives the server's certificate and must verify that the certificate was signed by a trusted root CA. If that chain breaks — missing intermediate CA, expired root, or the server's cert itself is expired — you get 0x0000360E.

I've seen this most often when someone generates a self-signed root CA on the VPN server, forgets to install its certificate into the client's Trusted Root Certification Authorities store, and then tries to connect. The client gets the server certificate, sees it's signed by an unknown root, rejects it.

Fix it

Skip the generic "check your firewall" advice. That won't fix this. The problem is certificate chain trust. Here's the fix.

Export the root CA certificate from the server.
If you're using Windows RRAS, open certlm.msc on the server, go to Trusted Root Certification Authorities > Certificates, find your CA cert, right-click > All Tasks > Export. Choose Base-64 encoded X.509 (.CER). If using strongSwan, the CA cert is usually /etc/ipsec.d/cacerts/ca-cert.pem — copy that file.
Install the root CA on the client.
On the Windows client machine, run certlm.msc (for local machine — this is per-machine, not per-user). Go to Trusted Root Certification Authorities > Certificates, right-click All Tasks > Import, select the exported .CER file. Complete the wizard. This tells Windows "this root is trusted".
Check the server certificate itself.
Open the server certificate in certlm.msc on the server. Double-click it, go to the Details tab, check Valid from and Valid to. If it's expired, you need a new cert. Also check the Certification Path tab — it should say "This certificate is OK" with no red X's.
Verify the intermediate chain.
If your server certificate was issued by an intermediate CA (not directly by the root), export that intermediate cert too and install it into the client's Intermediate Certification Authorities store. Without it, the client can't complete the chain.
Restart the VPN service.
On the server, run net stop IKEEXT && net start IKEEXT — that's the IKE and AuthIP IPsec Keying Modules service. On the client, restart the VPN connection. Don't skip this — stale sessions can hold old crypto state.

Still failing?

If you did all that and it still fails, here's what to check next.

Date and time on the client. If the client's clock is more than 5 minutes off from the server's, certificate validation can fail. Run w32tm /resync on both sides.
Certificate revocation check. Some VPN servers set the CRL Distribution Points extension in the certificate. If the client can't reach the CRL URL, it blocks the connection. You can test by adding certificate_revocation_check = no in strongSwan's strongswan.conf, or in Windows IKEv2 you can disable revocation checking via registry: HKLM\SYSTEM\CurrentControlSet\Services\IKEEXT\Parameters, create DWORD DisableRevocationCheck = 1. Use this only as a test — don't leave it off in production.
EKU mismatch. The server certificate must have the Server Authentication extended key usage (1.3.6.1.5.5.7.3.1). If it only has Client Authentication or nothing, the signature check rejects it. Regenerate the cert with correct EKU.

The fix that works for me 90% of the time is step 1 and 2: export the root CA, install it in the client machine's trusted root store. The rest is edge cases, but they happen often enough to check.