Which Machine Certificate Does the Windows VPN Offer?

Certificates are installed, the private keys are present, and the tunnel still fails authentication. A machine holding several certificates can hand the VPN a candidate nobody intended, and the client has no way to know which one the gateway would accept. Deleting the others is a selection policy with consequences for every service on the box. Narrow the eligible set instead, then confirm which certificate was actually offered.

Several Certificates, One Offered

Native Windows VPN profiles with machine-certificate authentication expose two filters that restrict the candidates: an issuer filter and an enhanced-key-usage filter. They reduce the set the client may choose from. They do not repair an unsuitable certificate, and they do not guarantee that the server accepts whatever remains. That boundary is worth stating in the change record, because the next reader will assume the filter decided more than it did.

The failure they address is narrow and specific. A valid certificate from the wrong authority, or one issued for a purpose the gateway does not accept, gets chosen ahead of the intended one, which produces an authentication failure next to a healthy store. Two filters turn that into a set small enough to reason about, and the rest of this page applies them in order.

Inspect the Store Before Editing the Profile

List the candidates and their properties in the store the profile actually uses. Nothing here exports a private key, and no certificate has to leave the machine:

Get-VpnConnection -Name 'Office' | Select-Object Name, TunnelType, AuthenticationMethod
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Issuer, Thumbprint, NotAfter, HasPrivateKey, EnhancedKeyUsageList

Read the output for the properties the decision depends on: a usable private key, an acceptable validity window, the intended issuer and the purposes in the extension. A certificate can be present, correctly enrolled and useless for this connection at the same time. The thumbprint column is what you will compare against later, so keep the output.

Confirm the profile and its scope before editing, because a machine certificate in LocalMachine, a user EAP-TLS certificate and an application's own private key store are three different contexts. Use the all-user scope and an administrative context when the managed profile lives there instead. Creating a second profile with a similar name conceals which configuration the connection actually uses.

The Issuer Filter Wants an Object

The issuer parameter expects a certificate object, not a display name and not a bare thumbprint string. Supply the approved authority's certificate from a path you have reviewed, in the store where it belongs:

$issuerPath = Read-Host 'Certificate-provider path for the approved issuer CA'
$issuer = Get-Item -LiteralPath $issuerPath
Set-VpnConnection -Name 'Office' -MachineCertificateIssuerFilter $issuer

Do not substitute the client's own leaf certificate, a different authority with a similar subject, or a freshly generated root merely because the parameter type accepts it. Two authorities can share a subject string, which is why the object matters more than the text. The Microsoft cmdlet reference documents both input types, and it is worth reading before the first edit rather than after the failed attempt.

The Usage Filter Wants an OID String

The enhanced-key-usage parameter takes OID strings, and the client authentication purpose is 1.3.6.1.5.5.7.3.2. Applying it restricts the candidates to certificates carrying that purpose, which is what a client-authentication deployment wants:

Set-VpnConnection -Name 'Office' -MachineCertificateEKUFilter '1.3.6.1.5.5.7.3.2'

The value is an array, so a deployment that needs several purposes passes them as a list. What the filter cannot do is add a purpose to a certificate: it is a selection expression evaluated against signed extensions, and no filter rewrites those, so a certificate missing the purpose has to go back through enrollment.

Keep user-certificate EAP configuration separate from machine-certificate filtering, since they live in different places and a change to one rarely explains a failure in the other. Check as well whether domain or device management owns the profile, because a local edit can be replaced at the next policy refresh without anybody touching the machine.

Prove Which Certificate the Client Offered

Establish a fresh connection and read the client and server authentication evidence for the identity you intended. When more than one certificate satisfies the filters, the result is a smaller pool rather than a pinned leaf, so the next attempt may choose a different member. Note the thumbprint that appears in that evidence and compare it with the one you recorded from the store.

A successful command is not a successful authentication. The result worth recording is the intended certificate authenticating under the managed policy while every unrelated certificate stays available to the services that depend on it. If the failure survives both filters, the remaining candidates are the place to look next rather than the profile as a whole.