RADIUS EAP-TLS certificate expired

radius certificate expired breaks EAP-TLS and PEAP when the authentication server presents TLS material past notAfter, or when clients still trust an old RADIUS CA.

Help desk tickets pile up with “Wi‑Fi connects but no network” or authentication failed on corp SSIDs. Laptops using certificate-based 802.1X stop associating while captive portals on guest VLANs still work.

Users blame drivers; openssl and RADIUS debug logs show the server cert dates. Fix PKI and redeploy trust profiles before pushing OS updates that actually make things worse.

First response

Collect SSID, EAP type (TLS, PEAP, TTLS), RADIUS server FQDN, and supplicant OS. Enable short-term RADIUS debug on FreeRADIUS or NPS event logs on Windows. Record server certificate notAfter from openssl to the RadSec or TLS port your deployment uses—not only UDP 1812.

PEAP still wraps TLS in a tunnel—the server cert must be valid even if user certs are separate.

Wireless incidents overlap VPN internal cert expired when the same CA signs both VPN and Wi‑Fi server certs—track inventories together.

What this error means

EAP-TLS performs a TLS handshake inside 802.1X between supplicant and authentication server. The server presents a certificate; clients validate chain, dates, and often expected CN or SAN patterns.

When that certificate expires, association fails before IP assignment. PEAP and TTLS have a similar outer TLS server certificate even when inner MSCHAPv2 continues unchanged.

Client certificates for user identity can also expire, producing different syslog lines. This article centers on RADIUS server expiry affecting entire SSIDs.

Common causes

NPS cert auto-enrollment stalled. Domain controllers stopped requesting Wi‑Fi templates after GPO changes.

FreeRADIUS certificate_file not reloaded. New PEM copied to /etc/raddb/certs but radiusd still served previous mmap.

RadSec listener using old cert. Controllers speak RadSec to cloud RADIUS; only that listener expired while legacy UDP still works for others.

Supplicants pinning old issuers. MDM pushed trust for a retired CA; valid new server cert fails as untrusted while not technically expired—still classify with openssl.

Duplicate RADIUS behind load balancer with mismatched PEMs. One node expired, producing flaky classroom outages.

Forgotten eduroam or guest SSID. Secondary RADIUS VIP still serves an annual cert nobody monitored.

Confirm from the outside

OpenSSL to RadSec

HOST=radius.example.com
echo | openssl s_client -connect "${HOST}:2083" -servername "${HOST}" 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

On-disk FreeRADIUS cert

openssl x509 -in /etc/raddb/certs/server.pem -noout -dates -subject

NPS export check

Export the certificate in use from the NPS server personal store and run openssl x509 -noout -dates on the export.

How to read the output

If live notAfter is past, renew server certificate and redistribute trust. If dates are valid but clients fail, inspect whether clients still trust a retired CA in the WLAN profile. EAP logs citing TLS Alert during certificate presentation narrow timing to server material.

Fix checklist

1. Identify TLS listener and port your SSID uses (RadSec versus legacy).
2. Prove expiry with live openssl, not only on-disk PEM mtimes.
3. Issue new server cert from AD CS, internal CA, or public CA per policy.
4. Install on every RADIUS node; restart radiusd or NPS.
5. Push updated root and intermediate chain via GPO or MDM profiles.
6. Re-test EAP-TLS with one pilot device before mass communication.
7. Renew client certificates if logs show user cert expiry after server fix.
8. Monitor RADIUS TLS notAfter separately from web certificates.

Communicate to users that deleting and re-adding the WLAN profile may be required after CA migration—even when server dates alone were the root cause.

radius certificate expired rollouts should include a pilot classroom or floor before enterprise-wide SSID changes. Capture FreeRADIUS or NPS debug timestamps showing successful TLS after renew. If RadSec fronts multiple controllers, renew every hop; openssl only the outermost IP misses expired material on a middle appliance.

Triage myths: driver updates rarely fix server notAfter. Disabling 802.1X on the SSID is not a durable fix. When guest Wi‑Fi works but corp SSID fails, that split almost always points to EAP server expiry or trust bundle staleness on the corporate profile—not ISP outages.

Post-incident, inventory every SSID that references the same RADIUS CN so the next template renewal does not surprise a satellite office using an older VIP.

Wireless architects should document RadSec versus EAP-TLS paths in the same runbook—radius certificate expired symptoms overlap, but openssl ports differ. After fix, spot-check Android and iOS separately; trust stores diverge even when server serial already changed.

Campus help desks should receive the new server serial or thumbprint in comms templates—power users compare against profile trust before calling NOC back.

When to use automation

Wi‑Fi certs hide on appliances, not marketing sites. Schedule live TLS handshakes against the RadSec or TLS port your controllers use. /check helps for companion web portals; RADIUS needs openssl or synthetic EAP from the network edge.

Alert 30, 14, 7, and 1 days ahead—user cert storms follow server expiry if MDM does not rotate client identities.