802.1X certificate authentication, end to end

Why certificates instead of a password

A pre-shared Wi-Fi key is a secret every device knows and any person can read off a screen. It gets texted to contractors, saved in personal password managers, and leaves with people who leave. Rotating it means touching every device you own, which is why it never gets rotated.

802.1X with certificates removes the shared secret entirely. Each device holds a private key it generated and cannot export in any ordinary way, and proves possession of it to get on the network. There is nothing to type, nothing to screenshot, and nothing to forward. When a laptop is lost you revoke one certificate rather than changing the password for the entire company.

The four pieces

• The supplicant — the device asking for access. macOS, Windows, iOS and Android all have one built in; you configure it with a profile rather than installing anything.
• The authenticator — the switch port or wireless access point. It blocks all traffic except the authentication exchange until the device passes, then opens the port, often onto a VLAN the RADIUS server names.
• The RADIUS server — Windows NPS, FreeRADIUS, Cisco ISE or Aruba ClearPass. It is what actually validates the certificate, checks revocation, and maps the certificate to a computer or user account.
• The certificate authority — issues the device certificates and the RADIUS server's own certificate, and publishes the revocation list. This is the piece a SCEP server puts in front of.

EAP-TLS, and why not PEAP

EAP-TLS is mutual TLS inside the 802.1X exchange: the device validates the RADIUS server's certificate, the RADIUS server validates the device's, and neither one ever sees a password.

PEAP-MSCHAPv2, the common alternative, tunnels a username and password instead. It inherits every problem passwords have — reuse, phishing, rotation — and adds one of its own: if a device is configured without validating the server certificate, an attacker standing up a lookalike SSID collects credentials directly. That misconfiguration is the default on more platforms than it should be.

If you are deploying 802.1X now, deploy EAP-TLS. The additional work is issuing the certificates, and that is what SCEP automates.

What goes in the certificate

This is where deployments fail. Enrollment almost always works first time; authentication is what breaks, because the names inside the certificate do not match what the RADIUS server expects to find.

• Device certificates need the fully-qualified hostname in a DNS subject alternative name. For Active Directory it has to match the computer object's dNSHostName attribute exactly.
• User certificates need the UPN as an otherName principal-name entry, OID 1.3.6.1.4.1.311.20.2.3. A UPN sitting in the subject CN is not enough — AD will not map it, and the failure message will not tell you that.
• Extended key usage should be clientAuth on device and user certificates, and serverAuth on the RADIUS server's. Keeping them apart means a stolen device certificate cannot be used to impersonate your RADIUS server.
• A CRL distribution point that your RADIUS server can actually reach from where it runs.

Get the SAN right before you enrol a fleet. Fixing it afterwards means re-enrolling every device.

The RADIUS server's own certificate

EAP-TLS is mutual, so the RADIUS server needs a certificate too, and the devices need to trust whoever issued it. Issuing it from the same CA as the device certificates is the straightforward path: the devices already carry that root, so they trust the server without any extra distribution.

Then configure the supplicant to pin it — trust that specific issuer and that specific server name, not "any certificate in the system store". A profile that trusts anything publicly-trusted is a profile an attacker can satisfy with a certificate they bought.

Revocation

Revocation is what makes a lost laptop stop working, so it is worth being precise about how it behaves.

Your CA publishes a certificate revocation list at a fixed URL. Every certificate it issues carries that URL inside it. Your RADIUS server fetches the list, caches it, and rejects any certificate on it.

An expired CRL fails closed. Validators do not treat "I could not fetch the list" as "nothing is revoked" — they reject the chain, and every device drops off the network simultaneously. Whatever CA you use, know how long its lists are valid for, how often they are regenerated, and what happens if the publication point is unreachable. If you would rather not depend on a third party being reachable, mirror the list to an address you control and have that address stamped into the certificates.

Rolling it out

1. Stand up the CA and issue the RADIUS server certificate first.
2. Distribute the root to devices, and configure the RADIUS server to trust it and to fetch the CRL. Confirm it can reach the CRL URL from its own network position.
3. Enrol one device and authenticate it against a test SSID or a single switch port. Check the certificate contents against what the server actually matched — this is the step that catches SAN mistakes while they are still cheap.
4. Revoke that device deliberately and confirm it stops authenticating after the server refreshes its list. If this does not work, nothing downstream of it works either.
5. Run the certificate SSID alongside the password one, and move departments across in batches.
6. Retire the password SSID only when the dashboard shows every device holding a valid certificate.

What usually goes wrong

• The SAN does not match. Symptom: enrollment succeeds, the device never gets on the network, and the RADIUS log says the identity could not be mapped.
• The CRL expired. Symptom: everything worked for weeks, then the whole fleet failed at once.
• The supplicant does not validate the server. No symptom at all — which is the problem. Check it deliberately.
• Nothing re-enrols. Certificates issued by hand, with no MDM behind them, expire quietly a year later. Let the management platform own renewal.
• Time drift. A device whose clock is wrong sees a valid certificate as not-yet-valid or expired, and the error it reports rarely mentions the clock.

ScepNet issues both the device certificates and the RADIUS server certificate, with the SAN and EKU shapes above, and publishes a CRL that is regenerated on revocation and refreshed well before it expires. The documentation covers the specifics.