Yeah, I know this error is a pain. You're trying to set up a VPN or IPsec connection and Windows just says nope — no valid machine certificate. Let's cut through the nonsense and get it fixed.
First Thing: Check Your Machine Certificates
Open the local machine certificate store. Not the user one, the machine one. That's the trick most people miss.
# Open this as Administrator
certlm.msc
Look under Personal > Certificates. You need a certificate with an Intended Purpose that includes IP security IKE intermediate or Client Authentication. Most small biz setups use a certificate issued by your company's internal CA or a purchased one. If there's no cert there, that's your problem.
But here's the thing — even if you see a certificate, Windows may not be picking it up for IKE. Common reasons: the private key isn't exportable, or the cert isn't in the right store.
The Real Fix: Re-import the Certificate Properly
Had a client last month whose print queue died because of a bad cert import. Same idea here. You need to import the certificate into the Local Machine store, not Current User.
- Get the .pfx file from your IT admin or CA.
- Double-click it. In the import wizard, choose Local Machine. Not Current User.
- Check Mark this key as exportable — yes, do it. Makes life easier later.
- Place it in Personal store. That's it.
After that, close certlm.msc and reopen it to verify. You should see the cert with a little key icon (private key attached). If not, the import didn't go right — try again with exportable checked.
Now test your IPsec connection. Usually works right away. If not, move to the next step.
Why This Happens
Windows IKE (Internet Key Exchange) needs a machine certificate to authenticate the computer. Not a user cert. I've seen setups where someone imported the cert as a user, then the IKE service can't find it. That's error 0X000035EE. Simple as that. The machine cert lives in the Local Machine store, and the IKE service only looks there.
Another common scenario: the certificate exists but doesn't have the right Extended Key Usage (EKU). Look at the cert details. You should see something like 1.3.6.1.5.5.8.2.2 (IP security IKE intermediate) or 1.3.6.1.5.5.7.3.2 (Client Authentication). If it's only for server authentication, IKE won't use it. That's a cert issue from your CA.
Less Common Variations
Sometimes the cert is fine but the crypto settings are off. Here's a few things to check:
1. Cert Revocation Check Fails
If your network can't reach the CRL distribution point (common in small offices with no internet for the VPN server), IKE bails. Try this:
# Disable CRL check for testing (only do this on a test machine)
netsh advfirewall set allprofiles settings remotemanagement disable
Better fix: add an exception for the CRL URL in your firewall. Or if it's internal, make sure the CA is reachable.
2. Wrong Certificate Store for 64-bit vs 32-bit
I once spent two hours on this. On a 64-bit Windows, some old apps look at the 32-bit certificate store. Open certlm.msc (64-bit) and certlm.msc from C:\Windows\SysWOW64 (32-bit). Yes, they're separate. Copy the cert to both stores. Sounds silly, but it fixed an issue for a client running QuickBooks VPN.
3. Group Policy Overwrites
If your company pushes certificates via GPO, check that. Sometimes a GPO removes or replaces certs automatically. Run gpresult /h gp.html to see what policies apply. If you see a cert policy that doesn't include the right cert, talk to your IT.
Prevention for Next Time
Don't let this happen again. Do these three things:
- Document your cert setup. Write down where the .pfx file is, who issued it, when it expires. I've seen companies lose their certs and panic.
- Set a cert expiration reminder. Use a calendar alert 30 days before expiry. Replace it before it becomes a problem.
- Use a certificate template with the right EKU. When requesting from your CA, pick a template that includes IP security IKE intermediate or Client Authentication. Standard Web Server won't work for IKE.
That's it. Should get you back online in under 15 minutes. If not, your cert is probably from the wrong CA or missing the private key. Check those first.