EAP-TLS Certificate Renewal and Guest MAC Randomization
A university hospital has 1,800 staff, 400 guest devices, and 3,000 IoT medical devices. The staff SSID uses WPA2-Enterprise with EAP-TLS against two RADIUS servers behind a load balancer. The guest SSID uses Portal authentication with MAC authentication fallback after two hours. On Monday, 600 staff laptops fail with 'EAP authentication failed'; the IoT devices stay connected. The RADIUS server certificate was renewed on Saturday. The new certificate is issued by an internal CA whose root was distributed only to domain-joined Windows machines. 300 macOS and 150 unmanaged Windows laptops fail. The guest portal also fails for 80 Android devices because MAC randomization gives a new MAC on each association, so portal sessions never persist. The hospital wants WPA3-Enterprise eventually but cannot replace 3,000 IoT devices that only support WPA2-PSK.
1. Separate the staff EAP-TLS failure into certificate-trust, RADIUS-chain, and client-configuration causes. What evidence would confirm each, and what is the fastest safe remediation?
Read the worked answer
Treat the three causes separately:
- Certificate trust: the new RADIUS certificate chains to an internal root trusted only by domain Windows machines. macOS and unmanaged Windows laptops fail with an unknown-CA TLS alert; domain Windows succeed. Evidence: RADIUS/load-balancer TLS alert 'unknown CA' for the failing clients, and openssl s_client showing the chain. Fast fix: distribute the root and any intermediate via MDM/configuration profile; do not disable server-certificate validation.
- RADIUS chain/load balancer: if some clients still fail after trust is fixed, check that the load balancer presents the full chain and that the RADIUS certificate has the correct EKU/server-auth and SAN. A missing intermediate produces the same unknown-CA symptom.
- Client configuration: EAP-TLS client certificates and supplicant settings may still point to the old CA. Check the client certificate issuer and validity; re-enroll if the client certificate was also renewed.
The IoT devices are unaffected because they use WPA2-PSK. That is a useful control: it rules out the AP/SSID and points to 802.1X/EAP.
2. Redesign guest onboarding to work with MAC randomization while keeping a two-hour fallback, and advise whether to enable WPA3 transition mode on the staff SSID now.
Read the worked answer
MAC authentication fallback is fundamentally incompatible with MAC randomization: the portal sees a new device each time, so the two-hour fallback never binds. Replace it with a device-bound credential: portal login that issues a per-device token/cookie stored in the browser, or 802.1X with a provisioned device certificate/profile for managed guests. For unmanaged guests, use a captive portal with a short session and no MAC fallback, and treat randomization as a new session. If MAC fallback is a business requirement, restrict it to known OUIs or to a dedicated SSID for fixed devices, not the general guest SSID.
For WPA3: do not enable WPA3-Enterprise transition mode on the staff SSID until all staff clients and the RADIUS chain support PMF and the chosen EAP method. A separate WPA2-PSK SSID for the 3,000 IoT devices is appropriate. WPA3 transition mode can create interoperability and PMF issues without solving the certificate-trust problem.