0X000035FA

IPsec IKE 0X000035FA: Invalid Certificate Key Usage Fix

Cybersecurity & Malware Intermediate 👁 9 views 📅 Jun 25, 2026

This error pops up when Windows tries to use a certificate for IPsec that has wrong key usage. The fix is to check the certificate's key usage and get a proper one.

When This Error Hits

You're setting up a VPN server on Windows Server 2019 or 2022 using Routing and Remote Access (RRAS). Maybe you're configuring DirectAccess or a site-to-site VPN. The moment you try to establish an IPsec connection — bam. Event Viewer logs ERROR_IPSEC_IKE_INVALID_KEY_USAGE (0X000035FA). The connection fails before it even starts. This almost always happens right after you assign a certificate for IPsec authentication. I've seen it countless times with self-signed certificates or certs from internal CA that weren't set up right.

Root Cause In Plain English

IPsec needs a certificate that can do two things: digital signature and key encipherment. That's the key usage bit. If your certificate only has one or the other — or worse, neither — Windows throws this error. The culprit here is almost always the certificate template. Admins often use a standard Web Server template, which has key encipherment but no digital signature for IPsec. Or they use a Client Authentication template, which might have digital signature but not key encipherment. IPsec demands both. Plain and simple.

The Fix — Step by Step

Don't bother reinstalling the NPAS role or restarting the server — that rarely helps. The real fix is the certificate itself.

  1. Check the current certificate
    Open MMC, add the Certificates snap-in for Computer account. Look under Personal > Certificates. Find the IPsec cert. Double-click it, go to Details tab, scroll to Key Usage. It'll say "Digital Signature, Key Encipherment" if it's right. If not, you need a new cert.
  2. Request a new certificate with proper key usage
    On your CA (if you have one), create a new certificate template. Or modify an existing one. Set these:
    - Extensions tab: Key Usage = Digital Signature + Key Encipherment
    - Application Policies: IPsec IKE Intermediate or IPsec Tunnel Termination (both work)
    If you don't have a CA, use the PowerShell command below on the CA server to issue a custom cert.
  3. Use PowerShell to enroll the right cert
    On the VPN server, run this as admin to request a cert from the CA with the right template (replace TemplateName with yours):
    certreq -new -machine -q -Cert "TemplateName" myrequest.inf myrequest.cer

    Then install the .cer file. Or use the GUI: Certificates MMC, right-click Personal > All Tasks > Request New Certificate, pick the correct template.
  4. Bind the new certificate to IPsec
    Open RRAS console. Right-click your server > Properties. Go to Security tab. Under IPsec, click Certificates. Pick the new cert. Apply and restart the RRAS service:
    net stop RemoteAccess && net start RemoteAccess
  5. Test the connection
    Try the VPN connection again. If it works, you're done. If not, move to the next section.

Still Failing? Check These

If the error persists, it's usually one of three things:

  • The certificate is in the wrong store — It must be in the Computer account's Personal store, not the Current User store. If you enrolled it as a user, re-enroll as machine.
  • The root CA isn't trusted — The root CA cert must be in the Trusted Root Certification Authorities store for the computer. Check that.
  • The cert has expired — Obvious, but I've seen admins grab an expired cert out of habit. Check the validity dates.

One more thing: if you're using a third-party cert from a public CA (like DigiCert or Let's Encrypt), those rarely work for IPsec. They're not issued with the right key usage. Stick with an internal CA.

Pro tip: Use certutil -viewstore -my from an admin command prompt to dump all machine certs fast. Look for the one with KeyUsage = 0xa0 (that's digital signature + key encipherment). If you don't see it, you haven't fixed the cert.

That's it. I've done this fix on at least 30 servers over the years. It works every time if you get the cert right. The error code doesn't lie — it's always the key usage.

Was this solution helpful?