Cannot connect: 802.1X, RADIUS, certificates
very common
“Nobody can get on the corporate SSID. Phones say cannot connect to network, or it keeps popping the password box back up.”
Likely causes
-
Server certificate expired, replaced, or its chain not presented
25%Everything worked until one specific moment, often overnight, and every platform broke at once with no config change. Server log shows the EAP exchange starting and dying in the TLS handshake. Check the expiry on the certificate the server presents and whether it sends the full chain: replacing a server certificate without pushing the new chain produces exactly this.
-
Shared secret mismatch, or the controller is not a defined RADIUS client
20%Server log has nothing at all for that device, or an unknown-client / bad-authenticator entry. Turns up after a controller swap, a new AP group with a different source interface, or an IP change: the server only answers clients it knows by address.
-
Network policy does not match this request
20%Server is reached and rejects, and the log gives an authorization or policy failure rather than a credential failure. Usual causes: the identity or called-station/SSID conditions no longer match, group membership changed, or the policy sits below a catch-all deny after somebody reordered the set.
-
EAP method or client profile mismatch
15%Server wants certificate-based EAP and the client profile is set to password-based, or the reverse. Machine-versus-user authentication is the same fault wearing a different hat: the device authenticates at the login screen and fails once the user logs in, or vice versa.
-
Client does not trust the issuing CA, or has no valid client certificate
12%One platform fails while the others work. Device prompts you to accept a certificate, or refuses silently. Root or intermediate never pushed to that device, MDM profile not applied, or the device certificate expired or was issued to the wrong subject.
-
Account state, MFA, or clock skew
8%A single user rather than the whole SSID. Password changed, account locked, MFA not satisfied, or the device clock is out far enough that a valid certificate looks expired. Certificate validation is time-sensitive, so check time on the client, the AP and the server.
What to bring
- Controller client-state and client-history view
- RADIUS server logs (the event for one specific failure)
- a test device you can build a profile on by hand
- browser or openssl to inspect the server certificate chain
- wired 802.1X test port
- NTP check on client, AP and server
Steps
-
Step 1: Prove it is authentication, not RF
Look at the client's state on the controller. Association succeeding while the EAP exchange fails or times out tells you the radio is fine and nothing about the antenna matters. Fastest confirmation available: join a PSK or guest SSID from the same AP in the same spot; if that works, the RF is not your problem.
If that doesn’t do it
Client never associates at all, or RSSI is poor: go to Full signal, no usable throughput or Heat map was green, the room is dead.
-
Step 2: Read the server log for one failed attempt, by timestamp
Get the time of a specific failure and pull that one event. The server almost always names the fault outright: unknown client, bad authenticator, policy mismatch, TLS failure, bad credentials. One log line saves an afternoon of theories.
If that doesn’t do it
No entry at all for that attempt: the request is not reaching the server. Check the shared secret, the client/NAS definition, the source interface and address the controller uses, and any firewall between them on the authentication and accounting ports the server is actually configured for.
-
Step 3: If it broke all at once, check the server certificate first
A simultaneous, all-platform outage with no change behind it is a certificate event almost every time. Verify the expiry, that the full chain is presented, and that the name clients validate matches what their profiles expect.
If that doesn’t do it
Certificate valid, chained and trusted: move to policy, step 4.
-
Step 4: Walk the request against the policy conditions
Take the attributes from the failed attempt (identity, called-station/SSID, group, device type) and walk them against the policy set in order. A new AP group, a renamed SSID or a reordered rule set breaks a policy nobody has touched.
If that doesn’t do it
Policy matches and it still rejects: look at the credential path, step 5.
-
Step 5: Test the supplicant in isolation
Build a profile by hand on one device: EAP method, identity, whether the server certificate is validated and against which CA. Then test the same credentials somewhere that takes Wi-Fi out of it: a wired 802.1X port or the server's own test facility.
If that doesn’t do it
Hand-built profile works and the pushed one does not: the fault is the MDM or GPO profile, not the network. Fix it there.
-
Step 6: Fix the cause, then remove the workaround
If you disabled server-certificate validation or stood up a temporary PSK SSID to get people working, write it on the ticket and take it out when the real fault is fixed. A disabled certificate check is a permanent hole that survives every future audit until somebody removes it.
If that doesn’t do it
Working for most and failing for a handful; treat those individually: client certificate, device clock, account lockout.
References
- IEEE 802.1X-2020
- IEEE 802.11-2020
- RFC 2865 (RADIUS)
- RFC 5216 (EAP-TLS)
- vendor controller and RADIUS server documentation