PIV Login Fails on Windows EAP-TLS? Check the Signing Path

Show a PIV card's certificate in every Windows dialog and the VPN login can still fail, because visibility and usability are different properties. The certificate is a public object; the login needs a private-key operation performed by the card under its own access rules. Between those two facts sit four stages that fail in four different ways: profile selection, certificate selection, local signing and server-side validation. Walking them in order turns a generic handshake error into a specific question for whoever owns the next piece.

Start With the Profile and the EAP Method

Open the connection's properties and read which EAP method the profile actually uses, then read which certificate the method is configured to select. Plenty of deployments have both a certificate-based outer method and an inner method, and a certificate configured at the connection level is not automatically the one presented inside EAP-TLS. If the profile picks a certificate by issuer or by subject filter, that filter selects from what Windows can see in the relevant store, not from what the card happens to contain. A filter that matches nothing falls back to a prompt or to a silent failure depending on the profile's configuration, which is why the selected thumbprint is worth recording before any change.

Also establish whether the connection runs as the signed-in user or as the machine. That single fact decides which certificate stores are in scope and which security context performs the signature.

Confirm Which Certificate Was Selected

Compare the thumbprint Windows chose against the requirement: client-authentication usage, a chain that terminates in a trusted root, an identity that the authentication server's policy maps, and a validity period that covers the actual moment of the attempt. Those are separate checks and the last one catches more surprises than people expect, particularly with certificates issued on a rolling basis and cached profiles that still point at yesterday's selection.

User and machine context is the other half of the check. A certificate in the user's personal store is invisible to a service running as the machine, and a machine certificate is not presented by a user-mode EAP exchange unless the profile says so. Reimporting a certificate into the wrong store produces a visible certificate and an invisible login credential. Read the store path in the profile, not the one in the dialog that happened to open.

Test the Key Operation Without Guessing the PIN

Once selection is settled, the question is whether the card will perform the signature. Windows needs a supported card provider or minidriver to reach the private key, and the device applies its own PIN and presence rules to the operation. A card configured to require a touch for every signature behaves differently from one that caches a verification for a session, and both are legitimate configurations that change when a prompt appears. That difference explains a login that succeeds on a fresh insertion and fails after a resume, without any certificate being wrong.

certutil.exe -scinfo
certutil.exe -store -user My
Get-WinEvent -LogName Application -MaxEvents 40 | Where-Object ProviderName -like '*Ras*'

The first command inventories the card and reports reader and provider state, which is documented in Microsoft's smart-card debugging guidance. The second lists what the user context can actually see. Neither proves a successful authentication; both narrow where it stopped.

Do not guess the PIN. Cards enforce retry limits, and a few optimistic attempts convert a permissions problem into a blocked credential that needs administrative recovery. If a local signature fails, capture the provider status and the card state instead of trying variations. Repeat the attempt once with the same profile, the same certificate and a known-good reader path, then compare the two records; changing several variables at once produces a story rather than a result.

Read Both Sides of the Handshake

A completed signature still is not admission. The authentication server must accept the chain, check revocation, map the identity under its current rules and authorise the request; the client must in turn validate the server's certificate as the profile requires. A TLS alert generated by the server looks identical in the client's log to one generated locally, which is why the emitting side matters more than the alert text.

Collect the Windows events and the server-side events with aligned timestamps, then identify which side produced the first failure. RFC 5216 describes the proof-of-possession step in EAP-TLS, and a generic handshake alert does not name a local key cause on its own. The timestamp comparison is what turns two logs into a sequence.

Keep the Boundaries Straight in the Report

Write the report as four stages with one verdict each: which profile and context ran, which certificate Windows selected, whether the card signed, and what the server decided. That structure makes the next step obvious and prevents the common repair of disabling validation to get past a stage nobody identified.

A software certificate as a temporary comparison is a legitimate administrator test, but it changes the credential and assurance model, so it belongs in an approved change rather than a quiet production workaround. The same discipline applies to PIN attempts and to reissuing credentials before the failing stage is known. A replacement card that fails identically is expensive evidence that the problem was never on the card.