Fix ERROR_IPSEC_IKE_INVALID_CERT_TYPE (0X000035FB)

What This Error Means

ERROR_IPSEC_IKE_INVALID_CERT_TYPE (0X000035FB) pops up when you try to connect to a VPN or IPsec tunnel, and the certificate you're using isn't the right kind of certificate for the server. It's not expired, and it's not revoked—it just wasn't made for this job. The server expects, say, a computer certificate for authentication, and you handed it a user certificate. Or vice versa.

I see this most often when someone uses a personal certificate (like one from a web server) for IPsec machine authentication. It also happens when you import a certificate from a different VPN configuration without checking its intended purpose.

30-Second Fix: Check the Certificate Purpose

Before you go digging through logs or rebuilding trust, do this quick check. It takes thirty seconds.

1. Open Certificates console. Press Win + R, type certlm.msc, hit Enter. (That's for local machine certificates. You'll see a warning about admin rights—click Yes.)
2. Expand Personal and click Certificates.
3. Find the certificate you're using for the VPN. Double-click it.
4. Go to the Details tab. Scroll down to Enhanced Key Usage.
5. Look for something that lists the purpose. You should see one of these:
   • Client Authentication (1.3.6.1.5.5.7.3.2) — for user-based VPN.
   • Server Authentication (1.3.6.1.5.5.7.3.1) — for the other end.
   • IPsec IKE Intermediate (1.3.6.1.5.5.8.2.2) — rare but correct for some IPsec setups.

What to look for: If the Enhanced Key Usage field says something like Any Purpose or lists only Server Authentication when you're a client, that's your problem. You need a certificate with the right purpose. If you don't see Client Authentication in that list, the server won't accept it.

If it's missing, you can't fix it here—you need a different certificate. Move to the moderate fix.

5-Minute Fix: Reissue or Import the Correct Certificate

You can't change a certificate's purpose after it's created. The real fix is getting one that's built for IPsec machine authentication. If you control the certificate authority (like an internal PKI), you can issue a new one. If you don't, you'll need to get one from your IT team or the VPN provider.

If You Use a Windows CA (Active Directory Certificate Services)

1. On the client machine, open Certificates console again (certlm.msc).
2. Right-click Personal, go to All Tasks, and choose Request New Certificate.
3. Click Next on the wizard. Select Active Directory Enrollment Policy if available, then click Next.
4. You should see a certificate template like Computer or IPsec. Select it. If you don't see an IPsec-specific template, pick Computer—that one includes Client Authentication by default.
5. Click Enroll. Wait for the status to say Succeeded. Then click Finish.
6. Now go back to the VPN connection and point it to this new certificate. In Windows VPN settings, you usually need to specify the certificate thumbprint or just pick it from a dropdown.

If You Get a Certificate from a Third-Party VPN (Like a .p12 File)

1. Open Certificates console for the local machine (certlm.msc).
2. Right-click Personal, go to All Tasks, then Import.
3. Browse to your .p12 or .pfx file. Type the password if it has one.
4. Place it in the Personal store. Finish the wizard.
5. Double-check the certificate's Enhanced Key Usage. It should have Client Authentication. If not, this certificate won't work either.

After importing, restart the VPN client service (or just reboot). Try the connection again. If it still fails with the same error, you've got a different problem—move to the advanced fix.

15+ Minute Fix: Dig into the IPsec Policy and Root Trust

Sometimes the certificate is fine, but the IPsec policy on one end is misconfigured. Or the root certificate isn't trusted properly. Let's check both.

Step 1: Verify the Root Certificate Is Trusted

The client needs to trust the certificate authority that issued the server's certificate. And the server needs to trust the CA that issued the client's certificate. If they're different CAs, both ends must have the other's root.

1. Open Certificates console (certlm.msc).
2. Expand Trusted Root Certification Authorities. Click Certificates.
3. Check if the CA that issued your VPN certificate appears in that list. If not, you need to import it. You can get the root certificate from your IT team or export it from another machine that already has it.
4. To import root certificate: right-click Trusted Root Certification Authorities, All Tasks, Import. Browse to the .cer file. Place it in the Trusted Root Certification Authorities store.

Step 2: Check IPsec Policy Settings (Windows Firewall with Advanced Security)

1. Open Windows Firewall with Advanced Security from Control Panel (or type wf.msc in Run).
2. In the left pane, click Connection Security Rules.
3. Find the rule for your VPN tunnel. Double-click it.
4. Go to the Authentication tab. See what it's set to. The most common settings are:
   • Computer and User (using Kerberos) — this requires domain membership and a computer certificate with Client Authentication.
   • User (User certificate) — this needs a user certificate with Client Authentication.
   • Advanced — you might need to specify a certificate thumbprint here.

The common mismatch: The rule says User certificate but you're using a computer certificate. Or vice versa. Change the rule to match the certificate you have. If you're not sure, try setting it to Computer and User (using Kerberos)—that's the most flexible for domain machines.

Step 3: Clear Stale IPsec Policies (Nuclear Option)

If none of this works, it might be a corrupt IPsec policy cache. Here's how to reset it cleanly.

1. Open an elevated Command Prompt (right-click > Run as administrator).
2. Type ipsec -flush and press Enter. This clears the security associations.
3. Type netsh ipsec static set policy name="MyPolicy" assign=n (replace MyPolicy with your policy's name). Then assign=y to reassign it.
4. If you're still stuck, go nuclear: netsh ipsec static delete policy name="MyPolicy" and rebuild the rule from scratch in Windows Firewall.

Pro tip: After flushing, reboot both ends. I've seen stale policies cause this error even when certificates were perfect. A fresh start clears it.

When All Else Fails

If you've tried all three steps and still get 0X000035FB, it's time to check the server logs. On the VPN server (if you have access), look at the IPsec or IKE logs. The server often tells you exactly what certificate type it expected. You might find it wants an IPsec IKE Intermediate certificate, which is a special template you'll need to create and issue.

That's rare but happens in some government or military-grade IPsec setups. In that case, your PKI administrator needs to create a certificate template with the IPsec IKE Intermediate extended key usage (1.3.6.1.5.5.8.2.2) and issue it to the client.

One more thing: check your system time. If the client's clock is more than 5 minutes off from the server's, certificate validation fails silently and shows this error. Sync with time.windows.com and try again.