EAP-TLS failures are miserable to troubleshoot for one structural reason: the client usually gets no useful error. The user sees "Can't connect to this network"; the supplicant saw a TLS handshake stop; the actual reason lives in a log somewhere else. The fix is to stop guessing and walk the dependency chain in order — because EAP-TLS only has a handful of moving parts, and each one has a definitive check.
The mental model
A successful EAP-TLS authentication requires all of the following, simultaneously:
- The client has a valid, unexpired certificate with its private key, suitable for client authentication.
- The client's certificate chains to a CA the RADIUS server trusts — including intermediates.
- The server has a valid certificate suitable for server authentication.
- The server's certificate chains to a CA the client trusts, and satisfies the client profile's server validation rules.
- The RADIUS policy accepts the identity derived from the client certificate.
- The transport works: the authenticator can reach the RADIUS server, shared secrets match, and large EAP packets survive the path.
Every EAP-TLS failure is a failure of one of these six. Check them in order.
Step 1: is the client certificate actually there and usable?
On Windows, open certlm.msc (device certs) or certmgr.msc (user certs) and find the certificate. Verify:
- It exists and is in its validity period. Obvious, and still the single most common cause — especially renewal failures on devices that were offline (see certificate renewal pitfalls).
- "You have a private key that corresponds to this certificate" appears on the General tab. A certificate without its key is a decoration.
- The EKU includes Client Authentication (1.3.6.1.5.5.7.3.2). A certificate with only other EKUs won't be offered for EAP-TLS.
- The subject/SAN contents are what your RADIUS policy expects. Decode the certificate and read the SAN — don't assume the profile produced what you designed. Missing or wrong SANs are the classic Android lesson but happen on every platform.
On macOS check Keychain Access; on Android and iOS, certificate visibility is limited, so decode a certificate from the issuing CA's records instead, and rely on server-side logs for the rest.
Step 2: does the server trust the client's chain?
The RADIUS server must be able to build a complete chain from the client certificate to a root it trusts. Two frequent failures:
- The issuing CA's certificate isn't installed on the server (or in its configured trust store). Common after moving from on-prem CA to a cloud CA: client certs now come from a new issuer nobody told the RADIUS server about.
- An intermediate is missing. If clients get certs from a two-tier PKI, the server needs the intermediate available. Symptoms are identical to a fully untrusted cert, which makes this maddening — build the chain explicitly and check every link is present server-side.
Also check revocation behaviour: if the server performs CRL checks and the CRL distribution point is unreachable from the server, valid certificates fail. This one is notorious after network changes and for CAs whose CDP is internal-only while the RADIUS server sits elsewhere.
Step 3: the server certificate, seen from the client
The client validates the server too, and modern supplicants are (rightly) strict:
- The server cert must have the Server Authentication EKU (1.3.6.1.5.5.7.3.1) and be unexpired. An expired RADIUS server certificate takes down everyone at once — if the failure hit the whole fleet simultaneously, check this first, not last.
- The client must trust the issuing root, deployed via a trusted certificate profile — and the Wi-Fi profile's server validation settings must match reality: the trusted root selected in the profile must be the one that actually issued the server cert, and if the profile specifies expected server names, they must match the certificate.
- After a RADIUS server certificate renewal from a different CA (or a switch from private to public CA), clients configured to trust the old root will refuse the new cert. Roll out client trust before rotating the server certificate.
Step 4: read the logs — Windows client side
Windows keeps genuinely useful 802.1X diagnostics; most people never look.
Event Viewer → Applications and Services Logs → Microsoft → Windows → WLAN-AutoConfig → Operational. Look for event 8002 (connection failed) and its neighbours; the failure reason text distinguishes association problems from authentication problems. "Explicit EAP failure received" means the conversation reached the RADIUS server and it said no — go read the server log. Failures before that point to client-side certificate or profile issues.
netsh wlan show wlanreport generates an HTML report combining the wireless event history, adapter state and profile list — the fastest way to see a timeline of what actually happened during a failed attempt.
Microsoft-Windows-CAPI2 → Operational (enable it first) records certificate chain validation, and shows precisely why a chain build failed — untrusted root, missing intermediate, revocation failure — when the client is the side rejecting the server certificate.
Step 5: read the logs — server side
The server almost always knows the real reason. On NPS, look in the Security event log for events 6272 (granted) and 6273 (denied); 6273 carries a reason code. The codes worth memorising:
| Reason code | Meaning | Usual fix |
|---|---|---|
| 16 | Credentials mismatch — the account couldn't be validated | For EAP-TLS: the certificate's identity (typically UPN SAN) doesn't map to a valid account — fix the SAN or the account |
| 22 | The EAP type cannot be processed | Server not configured for the client's EAP method, or server certificate missing/broken so the EAP module can't start |
| 48 | No matching network policy | Policy conditions (groups, NAS type) don't match this request — check policy order and conditions |
| 265 | Certificate chain issued by an untrusted authority | Install/verify the client cert's issuing chain on the server |
| 266 | Message unexpected or badly formatted | Frequently fragmentation — large EAP-TLS packets being dropped en route; check MTU and RADIUS packet handling on the path |
If there's no 6272/6273 at all, the request never arrived or was silently dropped: check network reachability from the authenticator, the RADIUS shared secret (a wrong secret makes the server discard packets, often with only an unobtrusive log entry), and whether the access point is pointed at the server you're watching.
Cloud RADIUS services expose equivalents through their dashboards — usually with friendlier messages than reason-code archaeology. The diagnostic logic is identical.
Step 6: transport gotchas
Two infrastructure failures masquerade as certificate problems:
- EAP fragmentation. EAP-TLS handshakes carry certificates and exceed single-packet sizes; they get fragmented. Paths that mishandle large RADIUS packets or fragments produce authentications that start and then stall or fail "badly formatted". Long chains and big RSA keys make it worse; if failures correlate with certificate chain length, suspect this.
- Timeouts. If the RADIUS server is slow (revocation checking against an unreachable CDP is a classic cause), the authenticator gives up and the client sees a generic failure. Server-side latency logging or a packet capture reveals it.
The triage shortcut
When the ticket lands, three questions locate the failure fast:
- Everyone, or one device? Everyone at once means server certificate, server outage, or shared secret. One device means client cert or client trust.
- Did the server log an attempt? No log entry means transport/secret. A deny entry with a reason code means you're one table-lookup from the answer.
- New rollout, or previously working? New means profile/SAN design; previously working means something expired, rotated, or a change rolled out gradually via renewal.
Work the chain, trust the logs over the client's error message, and resist the urge to re-enrol the device as a first move — it sometimes works, and then you've fixed one device and learned nothing about the other four hundred with the same fault scheduled for next week.