Staring at 0x00003610 after your VPN fails is annoying. I've been there. The error means your machine rejected the notify payload during IKE phase 2 — usually because the remote end's certificate authority isn't trusted locally.
The direct fix
- Check the certificate chain
Open certlm.msc (Local Machine certificate store). Look under Trusted Root Certification Authorities → Certificates. Find the root CA that issued your VPN server's certificate. If it's missing, that's your problem.
If the root is there, expand Intermediate Certification Authorities. The issuing CA needs to be here too. A missing intermediate is the most common cause of the notify payload failing — the client sees a broken chain and sends back an error instead of completing the negotiation.
- Install the missing root or intermediate
Export the cert from your VPN server (or get it from your admin). On the client machine, right-click the .cer file → Install Certificate. Choose Local Machine, then place it in the correct store. Root goes to Trusted Root, intermediate goes to Intermediate. Restart the VPN service with net stop RasMan && net start RasMan.
- Verify CRL/OCSP access
Windows checks certificate revocation by default. If your machine can't reach the CRL distribution point listed in the server cert, the chain validation might stall or fail. Check the server cert's details — look for the CRL Distribution Points field. If those URLs point to internal servers your client can't reach, you'll need to disable revocation checking for this connection. Run netsh advfirewall firewall set rule name="IKE" new enable=yes won't fix it — you need to adjust the IPsec policy.
Open gpedit.msc → Computer Configuration → Windows Settings → Security Settings → IP Security Policies on Local Computer. Right-click your policy → Properties → Settings tab. Under Key Exchange, click Methods → Advanced. Find the Certificate revocation dropdown. Set it to Do not verify certificate revocation. This isn't ideal for security, but if the CRL is unreachable, it's the only way to make the connection work.
Why this happens
The notify payload is part of IKE phase 2 — after the main mode (phase 1) establishes a secure channel, the quick mode (phase 2) negotiates the actual IPsec security associations. The 0x00003610 error comes from the ERROR_IPSEC_IKE_PROCESS_ERR_NOTIFY constant. What's actually happening here is the client receives a notify message from the server (like "certificate needed" or "invalid certificate") but can't process it because the local certificate store doesn't have the right chain.
The reason step 1 works is that IPsec on Windows validates the server certificate against the local machine store during quick mode. No trusted root means the validation fails, and the IKE service returns this error before sending your VPN traffic.
Less common variations
Group policy overriding local store
If you're on a domain, your IT might have pushed an IPsec policy that specifies specific trusted root CAs. That policy overrides the local machine store. Run gpresult /h gp.html and look under IP Security Policies. If you see a policy that restricts allowed CAs, you either need to add your server's CA to that policy or get IT to update it.
Server-side certificate expired
The error can also mean the server's certificate has expired. Check the server's cert validity from a machine that can connect. If the cert is expired, renew it. The client will still throw 0x00003610 because the notify payload contains a "certificate expired" message, and the client's IKE stack can't process it gracefully — it just fails.
Windows 11 vs Windows Server 2016 mismatch
Older VPN servers (Windows Server 2016 or earlier) sometimes use SHA-1 certificates. Windows 11 and Server 2022 disable SHA-1 by default for certificate chain validation. You'll see this error. Fix: either upgrade the server cert to SHA-256, or on the client enable SHA-1 temporarily via reg add HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002 /v Functions /t REG_SZ /d "IIS Crypto 2.0" — but really just update the cert.
Prevention
Keep your root and intermediate CA certs up to date across all machines that connect to your VPN. If you control the PKI, set the CRL distribution point to a public URL, not an internal-only one. Use SHA-256 certs — SHA-1 is already deprecated and will keep causing this exact error. Test certificate chain validation before you deploy a new VPN server: from a client machine, run certutil -verify server.cer. If it says "certificate is valid," you're good. If it throws errors, fix the chain before anyone tries to connect.
One last thing: if you see 0x00003610 paired with event ID 13801 in the System log under RasClient, it's 100% a certificate trust issue. Don't waste time tweaking IPsec lifetimes or rekey settings — they won't help.