ERROR_IPSEC_IKE_SRVACQFAIL (0x361F): IPSec Auth Fails to Get Credentials

You're setting up an IKEv2 VPN or a site-to-site tunnel, the connection drops, and the event log gives you ERROR_IPSEC_IKE_SRVACQFAIL with code 0x361F. The name is literal: the IKE service tried to acquire credentials (SRV ACQ = service acquisition) and couldn't. IKEv2 doesn't negotiate a key from thin air — it needs a machine certificate or a Kerberos ticket to prove the endpoint's identity. If neither is reachable, the connection fails right here.

In my experience the culprit is almost always the machine certificate store. Below are the three causes I've hit in the wild, ranked by how often they show up.

Cause 1: The machine certificate isn't where IKE expects it

What's actually happening here is that IKEv2 asks the local machine's certificate store for a cert with the correct EKU (usually IP security IKE intermediate, OID 1.3.6.1.5.5.7.3.17) and a subject name that matches the local endpoint identity. If it can't find one, or finds more than one and can't pick, you get 0x361F. This is the single most common reason.

A real trigger: someone issues the VPN cert to vpn.contoso.local as a user template instead of a computer template, installs it under Current User, and the IKE service — which runs as LocalSystem — never sees it. It only reads Local Machine\My.

Check what's actually in the store:

certutil -store My
certutil -store My "vpn.contoso.local"

Look for a cert with the right EKU. If the EKU is missing, IKE ignores the cert entirely even though it looks valid. Confirm with:

certutil -v -store My | findstr /i "1.3.6.1.5.5.7.3.17"

The real fix is to issue the certificate from a Computer template (or an equivalent template that includes the Client/Server Authentication and IP security IKE intermediate EKUs), let autoenrollment drop it into Local Machine\Personal, and bind it to the VPN connection. If you're using a manually imported PFX, import it into the machine store, not the user store:

Import-PfxCertificate -FilePath .\vpn.pfx -CertStoreLocation Cert:\LocalMachine\My

One more gotcha: if there are two valid certs in the store, IKE can pick the wrong one and fail the identity check downstream. Set the selection explicitly with Set-VpnConnection -Name "Contoso" -MachineCertificateIssuerFilter <thumbprint or issuer> or remove the stale cert.

Cause 2: Kerberos can't resolve or issue a ticket for the machine account

If you're using computer-based Kerberos authentication (no certificate), IKE calls into the local LSA to get a machine ticket for the remote endpoint, usually a service principal like HOST/<remote-fqdn>. If the SPN is missing, duplicated, or the domain controller can't be reached, the ticket request fails and you land on 0x361F.

This shows up most often on workgroup machines, machines in a different forest than the VPN gateway, or after a machine account password reset that didn't replicate. I've also seen it on cloned VMs where the same SPN got registered twice — Kerberos refuses to issue a ticket when it can't disambiguate.

Check SPNs on the target account:

setspn -L <RemoteMachineName>
setspn -X

setspn -X finds duplicate SPNs across the forest. If you see duplicates, remove the stale one. On the client side, verify the domain is reachable and the machine has a valid ticket:

klist -li 0x3e7
nltest /dsgetdc:contoso.local

If the machine account password is out of sync, resetting it usually clears this. On a workgroup client, Kerberos isn't available at all — switch to certificate authentication or PEAP. There's no way around that; Kerberos needs domain membership.

Cause 3: NPS/RADIUS or the local IPSec policy is misconfigured

Less common, but it bites when the certificate side is fine and Kerberos looks clean. On the gateway side, a Network Policy Server (NPS) policy can demand a certificate with a specific template name or a subject the client doesn't have, and IKE on the client interprets the resulting failure as a credential acquisition problem.

Common real-world cause: a Windows Server 2019 NPS policy set to require Contoso VPN Cert as the template, while the client got a cert from a renamed or different CA template. The names must match exactly, character for character.

On the client, check the local IPSec policy or Connection Security Rules:

netsh ipsec static show all
Get-NetIPsecRule

If a rule specifies an authentication method (certificate, Kerberos, or NTLM) that doesn't match what the peer expects, IKE tries to acquire the wrong credential type and fails. The fix is to align both sides. For IKEv2 VPNs specifically, confirm the VPN profile's authentication method matches the server:

Get-VpnConnection -Name "Contoso" | Select AuthenticationMethod

If the server expects EAP-MSCHAPv2 but the client profile is set to machine certificate, you'll get 0x361F on the client even though the server logs look fine. Fix the mismatch and reconnect.

Quick reference

Bottom line: 0x361F is almost never a network problem. It's a credentials problem. Check the machine cert store first — nine times out of ten that's where the answer is.