EAP-TLS Readiness Checker
A guided checklist wizard for certificate-based Wi-Fi: client cert, trust chains, server cert and profile settings — encoding the failure modes that cost people days.
✓ runs 100% in your browser — no data leaves this pageAnswer what you can verify — the verdict updates live and unverified items become your worklist.
| Is a client certificate present on the device/user store? | |
|---|---|
| Does that certificate have its private key? | |
| Is the client certificate unexpired? | |
| Does it carry the Client Authentication EKU (1.3.6.1.5.5.7.3.2)? | |
| Does it carry a UPN (or equivalent identity) SAN? | |
| Does the CLIENT trust the CA that issued the RADIUS server's certificate? | |
| Does the SERVER trust the CA that issues client certificates? | |
| Are intermediate CA certificates deployed (full chain available)? | |
| Does the RADIUS server certificate carry the Server Authentication EKU? | |
| Does the server name in the Wi-Fi profile match the RADIUS certificate? | |
| Is the SSID/wired profile set to certificate auth (EAP-TLS)? | |
| Can the APs/switches reach the RADIUS server (UDP 1812 / RadSec 2083)? | |
| Environment specifics |
Verdict: incomplete12 item(s) not verified yet. Work through them — every one is a real-world failure mode.
Client certificate present?Not verified yet — Without a client certificate EAP-TLS cannot even start. Check the SCEP/PKCS profile deployment status in Intune (Devices → Configuration → profile → Device status).
Private key present?Not verified yet — A cert without its private key (e.g. imported .cer instead of enrolled) cannot authenticate. Re-enroll via SCEP/PKCS rather than importing.
Client certificate valid?Not verified yet — Expired certificates are refused by the RADIUS server. Check the renewal threshold in the profile and whether the device has checked in recently.
Client Authentication EKU?Not verified yet — Most RADIUS servers require the Client Authentication EKU. Fix the certificate template / SCEP profile EKU list.
Identity SAN present?Not verified yet — Without a UPN/DNS SAN the server cannot map the certificate to an account. NPS requires it unless certificate mapping is customized.
Client trusts server CA?Not verified yet — The client aborts the TLS handshake if it cannot validate the server certificate. Deploy the server's root CA via a trusted-certificate profile, and reference it in the Wi-Fi profile's server trust settings.
Server trusts client CA?Not verified yet — The server rejects client certificates from unknown CAs (NPS: reason code 265 'untrusted CA'). Import the issuing CA chain into the server's trust store / cloud RADIUS trusted CA list.
Full chain available?Not verified yet — A broken chain fails validation even when the root is trusted. Deploy intermediates to clients (and configure the server to send its full chain).
Server Authentication EKU?Not verified yet — Clients refuse the TLS handshake. Reissue the RADIUS server certificate with the Server Authentication EKU.
Server name matches?Not verified yet — If the Wi-Fi profile pins a server name/suffix that doesn't match the RADIUS certificate, clients silently fail or prompt. Align the profile's 'connect to these servers' value with the certificate subject/SAN.
Profile method is EAP-TLS?Not verified yet — The network profile must specify EAP-TLS (certificate) — a PEAP/MSCHAPv2 profile will prompt for username/password instead of using the certificate.
RADIUS reachable?Not verified yet — Check the NAS (AP/controller/switch) shared secret and connectivity — timeouts at this layer look identical to auth failures on the client.
Frequently asked
What's the most common EAP-TLS failure?
Trust, in either direction: the client doesn't trust the RADIUS server's CA, or the server doesn't trust the client certificate's issuing CA. Both look like 'Can't connect to this network'.