Fix ERROR_IPSEC_IKE_NO_PUBLIC_KEY (0x00003604) Fast

Cause 1: Certificate Template Doesn't Include Public Key

This is the one I see most often. Someone enrolled a certificate using a template that doesn't have the proper key usage for IPsec. The error 0x00003604 means the server sent a certificate during IKE negotiation, but that certificate has no public key — or the public key is marked for something that IPsec can't use.

The fix is to issue a new certificate from a template that includes Digital Signature and Key Encipherment in the key usage. On a Windows CA, the built-in IPsec (Offline Request) template works. But if someone used a generic Web Server or Computer template, you'll hit this.

Step-by-step fix

1. Open the Certificate Authority console on your CA server.
2. Right-click Certificate Templates and select Manage.
3. Find the template your VPN server is using. If it's Computer or Web Server, that's your problem.
4. Duplicate the IPsec (Offline Request) template or create a custom one with these settings:

Key Usage: Digital Signature, Key Encipherment
Application Policies: IP security IKE intermediate, IP security user
Subject Type: Computer
Validity: Set to match your environment (1 year is safe)

5. Issue a new certificate from this template on the VPN server.
6. Rebind the certificate in your VPN service (RRAS or strongSwan) and restart the service.

I've fixed this exact issue at least a dozen times on Windows Server 2016 and 2019. The Computer template looks like it should work, but it doesn't include the right OID for IPsec IKE. Don't bother checking the cert in the MMC — it'll show a public key there. The problem is the template doesn't mark that key as usable for IPsec.

Cause 2: Certificate Was Enrolled Without Private Key

Sometimes the certificate enrolls, but the private key doesn't get stored properly. This happens more often with auto-enrollment or when someone exports/imports a cert without including the private key. The error message is identical — the peer sees a cert with no public key because the key pair didn't make it.

The easiest way to check: open the certificate on the VPN server, go to the General tab, and look for the line "You have a private key that corresponds to this certificate". If you don't see that, the private key is missing.

How to fix it

1. Delete the broken certificate from the local machine store (Certificates MMC > Local Computer > Personal).
2. Request a new certificate from the CA. Make sure you check Mark the key as exportable if you'll need to move it later — but for a straight enrollment, just let it create a new key.
3. If you're using strongSwan or a Linux-based IKE daemon, verify the private key file exists and has correct permissions:

ls -la /etc/ipsec.d/private/
openssl rsa -in /etc/ipsec.d/private/vpn-key.pem -check

If openssl says unable to load Private Key, you need to re-enroll or regenerate the key pair. On Linux, certool or easy-rsa can generate a fresh one. On Windows, just delete the cert and let auto-enrollment do its thing again.

Cause 3: Certificate Chain or CA Trust Issue

Less common, but I've seen it. The peer has the certificate but can't validate the chain. When the root CA certificate isn't trusted or intermediate CAs are missing, some IKE implementations (especially older ones) will throw 0x00003604 instead of the more common 0x00003605 (certificate validation failure).

This happens when you replaced a CA or changed its certificate without updating clients. The VPN server presents a cert signed by the old CA, and the client can't find the root.

Check and fix chain

1. On the VPN server, run certlm.msc and look at the server certificate. The certification path should show all intermediate CAs and end at a trusted root.
2. If any certificate in the chain shows an error, import the missing CA certificates into the Trusted Root Certification Authorities or Intermediate Certification Authorities store on both server and client.
3. For Windows clients, push the root CA via Group Policy: Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities.

I've seen this with Windows Server 2012 R2 when people used a standalone CA that wasn't in the domain's trusted store. The fix is always the same: get the root CA cert, distribute it to all peers, and restart the IPsec service.

Quick Reference Summary