Skip to content

Understanding EAP-TLS, PKI and RADIUS

This page explains the standard, vendor-neutral building blocks behind certificate-based network authentication: RADIUS, 802.1X, EAP-TLS, and the PKI that issues the certificates. It is intended as background reading; for product-specific configuration see the EasyRadius and EasyScep guides.

RADIUS and 802.1X: the roles

RADIUS (Remote Authentication Dial-In User Service, RFC 2865) is a protocol for Authentication, Authorization and Accounting (AAA). In a Wi-Fi or wired LAN deployment it works alongside IEEE 802.1X, which defines three roles:

  • Supplicant — the client device requesting network access (laptop, phone, tablet).
  • Authenticator — the network access device the client connects through (wireless access point, switch, or VPN gateway). It blocks all traffic except the authentication exchange until the client is authorized.
  • Authentication server — the RADIUS server that decides whether the supplicant is allowed on the network.

The authenticator relays authentication messages between the supplicant and the RADIUS server but does not make the decision itself. The RADIUS server and the authenticator trust each other via a shared secret; the RADIUS server and the supplicant establish trust using EAP.

EAP and EAP-TLS

EAP (Extensible Authentication Protocol, RFC 3748) is a framework that carries different authentication methods. EAP-TLS (RFC 5216) is the method that uses TLS with client and server certificates — there are no passwords involved.

At a high level, an EAP-TLS authentication performs a mutual TLS handshake:

  1. The RADIUS server presents its server certificate. The supplicant validates it against a trusted root — this is what stops a rogue "evil twin" server from impersonating your network.
  2. The supplicant presents its client certificate. The RADIUS server validates the certificate chain, checks it has not been revoked, and confirms it is trusted.
  3. If both sides are satisfied, the handshake completes and the RADIUS server tells the authenticator to grant access.

Because authentication is mutual and based on certificates, no reusable secret is ever transmitted over the air. (For why this matters compared with password-based Wi-Fi, see Why EasyRadius Uses Certificate-Based Authentication.)

The PKI behind the certificates

The certificates used in EAP-TLS come from a Public Key Infrastructure (PKI):

  • A Certificate Authority (CA) issues certificates and signs them with its private key. Devices trust certificates that chain up to a Root CA they have been configured to trust.
  • A client (leaf) certificate identifies the user or device. It carries a public key, an identity, and usage constraints.
  • Revocation lets you invalidate a certificate before it expires, published via a CRL (Certificate Revocation List) or checked in real time via OCSP (Online Certificate Status Protocol). A RADIUS server can consult either mechanism to reject revoked certificates. EasyRadius itself uses OCSP — see Certificate revocation checking.

For managed devices, the CA is usually reached through an MDM enrolment pipeline (for example Microsoft Intune with the SCEP protocol), so certificates are deployed automatically rather than by hand.

How a certificate expresses identity

Two parts of a client certificate matter for EAP-TLS:

  • Subject / Common Name (CN) — a human-readable name. Historically the primary identity field, but on its own it is increasingly not treated as authoritative by clients and servers.
  • Subject Alternative Name (SAN) — the modern, structured place for identities: DNS names, email addresses, or a User Principal Name (UPN). Many platforms now validate identity from the SAN rather than the CN.
  • Extended Key Usage (EKU) — constrains what the certificate may be used for. Client certificates for EAP-TLS must include Client Authentication (OID 1.3.6.1.5.5.7.3.2).

Android gotchas

Android Enterprise is stricter than some other platforms about how the client certificate is issued, and the failures tend to be silent. If you deploy EAP-TLS to Android devices, watch for the following:

  • BYOD Work Profile needs a User certificate, not a Device certificate. On a personally-owned Work Profile, a Device certificate may enrol but the Work Profile network stack cannot bind to it, so the Wi-Fi/VPN profile never applies — with no obvious error.
  • The UPN must be in the SAN, not just the CN. Android validates the Subject Alternative Name before it applies the Wi-Fi profile. The UPN has to be present as an otherName entry using the Microsoft UPN OID 1.3.6.1.4.1.311.20.2.3. A UPN placed only in the Common Name is not accepted.
  • The symptom is easy to misread. With Microsoft Intune the failure typically surfaces as error 0x87d1fde8 (-2016281112) on the profile, which looks like a profile/network problem but is really a certificate problem.

Because SAN validation happens before the profile is applied, always verify the issued certificate's contents first when Android EAP-TLS fails — check the certificate type and that the UPN is in the SAN.

Further reading