Wi‑Fi Enterprise (802.1X) certificate expired

Laptops report “Can’t connect to this network” on WPA2-Enterprise while phones on PSK still work—often the RADIUS server certificate used for EAP-TLS or PEAP expired, not the Wi‑Fi password.

Network operators troubleshooting wifi certificate expired patterns see help-desk spikes when domain-joined devices refuse corporate SSIDs. 802.1X authentication wraps EAP inside TLS between supplicant and RADIUS (NPS, FreeRADIUS, Cisco ISE, Aruba ClearPass). The server presents an X.509 certificate during EAP-TLS or the TLS tunnel inside PEAP.

Clients with strict validation block association when notAfter passed. Guest VLANs and PSK SSIDs may keep working, masking a RADIUS-only outage until executives cannot reconnect after sleep.

First response

Confirm the failure scope: one SSID or all 802.1X networks, one OS or all platforms. Collect supplicant logs—Windows netsh wlan show tracelog, macOS Wi‑Fi diagnostics, Android adb logcat with wpa_supplicant tags.

Identify RADIUS virtual server certificate names versus Wi‑Fi controller admin cert (different listeners). Test TLS to RADIUS Auth port (often radius.example.com:1812 does not speak TLS—many deployments use radsec 2083 or TLS on 1812 with RadSec).

Document whether PEAP uses server cert validation while MSCHAPv2 handles user auth—expired server cert breaks PEAP even with valid passwords.

Map each SSID to authentication profile in your WLAN controller export (wlan.xml or vendor equivalent) so responders know which RADIUS server cert applies. Include building site in the ticket—site-to-site VPN asymmetry sometimes means headquarters openssl looks fine while branch offices hit expired regional RADIUS.

What this error means

EAP methods encrypt credentials inside TLS tunnels. Supplicants validate the RADIUS server certificate against trusted CAs (or pinned names). Expired server material aborts before user authentication. EAP-TLS with client certificates adds a second expiry axis for user/device certs—distinguish server versus client in tickets.

Controller captive portal HTTPS is unrelated unless mis-reported by users. WPA3-Enterprise uses the same PKIX rules for server certificates presented during EAP.

MDM-delivered Wi‑Fi profiles may pin a specific RADIUS server name—renewing with a new CN without updating profiles looks like expiry to clients even when openssl shows a fresh date on a different name.

Conference season wireless stress-tests RADIUS chains when thousands of new devices associate within minutes—schedule renewal windows away from major events when possible.

Common causes

Active Directory CS Web Server template cert on NPS expired while admins renewed only the LDAPS cert on domain controllers. FreeRADIUS tls block still references server.pem copied three years ago; radiusd -X would show TLS errors under load.

RadSec load balancer VIP certificate expired while individual RADIUS nodes were healthy behind NAT. Controller-to-cloud RADIUS proxy used a SAS URL whose HTTPS cert expired, blocking auth to a healthy backend. Staged RADIUS migration left half of APs pointing at an old IP with expired cert.

BYOD onboarding portals that issue device certs are separate from RADIUS server certs, yet help desks conflate them—openssl both when tickets mention “Wi‑Fi certificate.” Eduroam deployments chain federation TLS with institutional RADIUS—expiry might be local to your IdP TLS while visitors blame eduroam globally.

Confirm from the outside

Reproduce from a wireless client subnet, not only from NPS itself—controllers may present a healthy inner cert while supplicants see an expired VIP. Document SSID, EAP type, and RADIUS profile name in openssl notes. If multiple RADIUS servers load-share, probe each backend IP or DNS name separately before blaming the Wi‑Fi vendor.

RadSec or TLS-wrapped RADIUS (deployment-specific host/port):

openssl s_client -connect radius.example.com:2083 </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

If you terminate TLS on NPS with a published cert, test the hostname clients expect in PEAP:

openssl s_client -connect nps.example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -dates

FreeRADIUS debug on a test AP VLAN:

sudo radiusd -X

Watch for SSL routines or certificate has expired during association attempts.

Compare with dedicated RADIUS EAP-TLS certificate expired guidance when client cert auth is primary.

Windows netsh wlan show networks lists SSIDs but not cert detail—use netsh ras show tracing only after you already proved server cert expiry with openssl from an NPS perspective or RadSec test host.

How to read the output

Server cert SAN/CN should match what supplicants expect (nps.corp.example.com). notAfter must be future. Issuer must chain to a CA distributed via GPO/MDM profile—renewing server cert without publishing new CA chain causes trust errors mistaken for expiry.

Fix checklist

1. Map SSIDs to RADIUS profiles and server cert templates.
2. OpenSSL or RadSec test each RADIUS TLS endpoint clients hit.
3. Renew server certificate (and client cert CA if EAP-TLS).
4. Install on NPS, FreeRADIUS certs/, or ISE admin upload.
5. Restart RADIUS services; reload controllers if they cache TLS context.
6. Push updated trust profiles via GPO/Intune if issuer changed.
7. Pilot reconnect on Windows, macOS, iOS, and Android corporate devices.
8. Monitor RADIUS TLS names separately from guest portal HTTPS.

Publish user comms before rotating RADIUS server certs when Android or iOS profiles pin names—some devices prompt trust dialogs, others fail silently until MDM pushes updated trust anchors. Validate wired 802.1X on the same RADIUS farm if your LAN shares authentication policy.

Record controller and NPS versions in the ticket—some firmware releases improve RadSec reload behavior and reduce full restart requirements after server cert swap.

When to use automation

Wi‑Fi controllers report “AP up” while 802.1X fails silently. Probe live TLS on RadSec and PEAP server certificate hostnames from inside the corporate network and guest VLAN paths. Public /check applies only if the RADIUS TLS name is internet-routable (uncommon).

Alert 30, 14, 7, and 1 days; Wi‑Fi outages affect entire sites. Track RDAP on domains in cert SANs used for BYOD onboarding portals if those share PKI.

Campus-scale deployments should monitor RadSec from both staff and student VLAN egress paths—ACLs can hide expired certs visible only from one role. /check rarely reaches internal RADIUS names; use ssldays-style internal polling or existing RADIUS EAP-TLS certificate expired runbooks on the same cadence.

Physical security and NAC integrations that reuse RADIUS configs fail alongside laptops—correlate badging outages with cert tickets before splitting incidents across teams.

Hospital and factory floors may keep devices connected while laptops retry—survey failure rates per SSID before closing tickets. Guest SSIDs with captive portal HTTPS can confuse executives who think “Wi‑Fi is broken” when only 802.1X is affected—publish status pages distinguishing them.

Controller firmware upgrades sometimes reset RADIUS profile bindings to expired defaults—diff RADIUS configs before and after every controller upgrade. Certificate Transparency does not help private RADIUS certs; internal PKI portals should emit their own renewal tickets ninety days ahead.

Help desk scripts should ask whether Ethernet desk phones on 802.1X also fail—yes confirms RADIUS cert, not only Wi‑Fi RF issues. After fix, run a structured reconnect test on intentionally locked devices before mass “please forget network” communications.

Facilities teams should be looped in when hospital or factory SSIDs fail—clinical and safety workflows may depend on handhelds even when laptops appear unaffected at HQ.

Network operations should monitor RadSec VIP names and PEAP server cert DNS entries even when they are private—internal synthetics from NOC tooling beat waiting for thousands of help-desk calls. Pair wireless controller uptime with RADIUS TLS checks because controllers can show green while authentication fails.