Can wpa_supplicant use a PFX file instead of separate PEM files?

Yes. A PKCS#12/PFX file can provide both the client certificate and private key to wpa_supplicant through private_key. Omit client_cert for that bundle and supply its passphrase through the control interface or another supported credential mechanism.

Why might Windows ignore an installed client certificate?

Windows may ignore an installed EAP-TLS certificate when it fails the Wi-Fi profile's issuer or extended key usage filters. If both filters are enabled, the certificate must satisfy both to be considered for authentication.

What happens to a Windows 11 server certificate pin after renewal?

The stored thumbprint still identifies the old certificate, so a Windows 11 profile that relies only on that pin needs an update after renewal. A profile that also has a valid CA and server-name configuration may accept the replacement through that separate trust check.

How can a Windows profile allow two RADIUS server names?

Separate the two permitted RADIUS server names with a semicolon in the Windows EAP-TLS profile's allowed-server-name setting. Require each server's certificate to match a listed name under the approved CA policy.

Can a smart card hold the client's EAP-TLS credential?

Yes. Windows can use a smart card certificate as the EAP-TLS credential. Select Use my smart card in the EAP-TLS profile and provision a suitable certificate on the card; setting a private-key file path does not select a smart card.

Does standalone EAP-TLS need the FreeRADIUS inner-tunnel server?

No. Standalone EAP-TLS authorizes the client certificate through its own processing path, including check-eap-tls in this example. The inner-tunnel server handles the separate authentication inside methods such as PEAP or EAP-TTLS, so a password user there is unnecessary for standalone EAP-TLS.

Does a successful radtest result verify this Wi-Fi setup?

No. A conventional radtest username-and-password request does not perform the laptop's EAP-TLS certificate exchange. It can test a basic RADIUS request path while leaving wireless certificate authentication untested.

What can eapol_test check without a wireless AP?

eapol_test can run a client's EAP method against a RADIUS server without using an AP or a wireless radio. It combines an EAP peer with a RADIUS client, so success can show that the method works between them while leaving the real AP's wireless connection and key exchange untested.

Are several Access-Challenge packets normal during EAP-TLS?

Yes. Multiple RADIUS Access-Challenge packets can be part of one EAP-TLS handshake when large certificate messages are split into fragments. Repeated challenges alone do not indicate rejection, but repeated restarts or a final failure need investigation.

Does TLS 1.3 improve certificate privacy in EAP-TLS?

Yes. EAP-TLS with TLS 1.3 encrypts certificate messages and requires an initial identity that contains no permanent client identifier in cleartext. These protections require an EAP-TLS connection that uses TLS 1.3; a profile using TLS 1.2 does not provide them.

How to Set Up Wi-Fi EAP-TLS with FreeRADIUS

Set up Wi-Fi EAP-TLS by registering the access point with FreeRADIUS, configuring server and client certificates, and enforcing a rule for enrolled devices. EAP-TLS uses Transport Layer Security (TLS) within the Extensible Authentication Protocol (EAP) to authenticate the client and server with certificates. Certificate verification and permission to join the network are separate decisions.

Start with one access point (AP), one enrolled laptop, and an isolated test wireless network identified by its service set identifier (SSID). Testing one connection makes a failed certificate check easier to trace before deploying the profile to more devices.

The configuration below targets FreeRADIUS 3.2.x. The examples use FreeRADIUS 3.2.9 syntax. Check your installed package and its configuration files before editing; FreeRADIUS 4 examples may require different settings.

How the Laptop, AP, and FreeRADIUS Work Together

The laptop's supplicant, the software that handles network authentication, exchanges EAP messages with the AP. The AP relays those messages through the Remote Authentication Dial-In User Service (RADIUS) protocol and controls whether the laptop can join. FreeRADIUS is the authentication server: it handles the TLS exchange and evaluates the client certificate.

For this example, the RADIUS server is 10.40.30.10, the AP's RADIUS source address is 10.40.30.20, and the SSID is Corp-Cert. The server certificate identifies radius.auth.example.com. These are illustrative values to replace with your network's addresses, SSID, and certificate name.

Keep the AP-to-RADIUS traffic on a controlled management network. If that connection must cross an untrusted network, use a protected transport supported by both systems rather than exposing ordinary RADIUS/UDP to the internet.

Prepare Certificates with Separate Purposes

Provision a RADIUS server certificate with Server Authentication extended key usage, the certificate field that identifies its permitted purpose. Put the intended DNS hostname in the Subject Alternative Name (SAN) extension, which lists names covered by the certificate. Each laptop needs its own Client Authentication certificate and matching private key; the key usage, chain of issuing certificates, and validity period must also be acceptable to the TLS software.

Use your managed certificate authority (CA), the issuer that signs certificates, and its enrollment process. The demonstration CA and certificates supplied with FreeRADIUS can be used in a disposable lab. Keep those test credentials separate from a production SSID.

For the example laptop, the CA assigns device-001 as the certificate's unique common name. The authorization rule below checks that name. Configure the CA to issue certificates with that common name only for this laptop. A name that anyone can request cannot reliably identify the authorized laptop.

Install only the required public CA certificates where trust is needed. The CA signing key stays with the issuer. The server's private key stays on the RADIUS server, and the laptop's private key stays on that laptop or its protected credential device.

Check the clock on the laptop and the RADIUS server before testing. A correctly issued certificate can still fail because its validity period has not started or has already ended. Record each certificate's issuer, serial number, expiration date, and enrolled device so renewal or removal can target the right credential.

Register the AP as a RADIUS Client

In clients.conf, add a client definition for the source address of the AP packets that FreeRADIUS receives. Set ipaddr = 10.40.30.20/32 for this single-AP example. A controller may send the packets instead, so confirm their source address rather than relying on the NAS-IP-Address attribute, which identifies the network access server inside the request.

Generate a strong random shared secret and configure the same value on the AP and in its FreeRADIUS client definition. Keep the secret out of screenshots and shared configuration copies. It supplies a key for RADIUS packet authentication and integrity checks; the laptop uses its own certificate key for EAP-TLS.

Set require_message_authenticator = yes for this client on a maintained 3.2.x installation. Message-Authenticator checks a RADIUS packet's integrity using the shared secret, and packets carrying EAP messages require it. If that check fails, fix the AP settings or software instead of removing the requirement.

On the AP, select WPA2-Enterprise for Corp-Cert so network authentication uses the RADIUS service. Configure the matching server address, authentication port, and shared secret, and allow UDP 1812 to the server only from the authorized AP or controller. Keep the test SSID's network assignment fixed; choosing a virtual LAN (VLAN) dynamically adds another access policy to verify.

Configure the FreeRADIUS EAP Module

Locate the package's active configuration directory from its startup output. It may be called raddb or use a distribution-specific path. Work with the existing mods-available/eap file and its mods-enabled entry, retaining unrelated settings that your installation needs.

Within eap, set default_eap_type = tls. Update the existing tls-config tls-common subsection with your actual certificate paths. The following is an excerpt, not a replacement for the entire EAP module:

tls-config tls-common {
    private_key_file = /etc/freeradius/3.0/certs/radius-server.key
    certificate_file = /etc/freeradius/3.0/certs/radius-server-fullchain.pem
    ca_file = /etc/freeradius/3.0/certs/wifi-client-ca.pem
    auto_chain = no
    tls_min_version = "1.2"
    tls_max_version = "1.2"
}

The full-chain file contains the server certificate followed by its intermediate issuing certificates, excluding the root. The client-CA file contains the CA certificates FreeRADIUS trusts to issue client credentials. Remove any inherited ca_path setting that would add unintended trusted issuers.

Use the real passphrase if the server key is encrypted; do not retain the example private_key_password from the distributed configuration. The service must be able to read its key, with file permissions limited to the accounts that need it.

The TLS 1.2 minimum and maximum give this 3.2.9 example a defined protocol range. Check TLS 1.3 support in the actual server build and client authentication software before changing that range. Do not lower the minimum to solve an unexplained connection failure.

Enable the TLS Method and Keep EAP Processing

In the existing tls subsection, retain tls = tls-common and enable virtual_server = check-eap-tls. A virtual server is a named configuration that processes requests; enable check-eap-tls through the package's sites-enabled mechanism. Keep the existing eap calls in the main virtual server's authorize and authenticate sections.

Changing the default EAP type does not disable every other loaded method. For a dedicated certificate-only service, disable unused method subsections after checking whether the same module serves other networks. Do not globally force Auth-Type = Accept to make a failing EAP exchange pass.

Authorize the Enrolled Certificate

The check-eap-tls virtual server runs after certificate verification and before the final acceptance. Its distributed example accepts by default, so replace that unconditional acceptance with an explicit policy.

For the single enrolled laptop, the authorize section can use this controlled certificate identity:

authorize {
    if ("%{TLS-Client-Cert-Common-Name}" == "device-001") {
        update config {
            &Auth-Type := Accept
        }
    }
    else {
        update config {
            &Auth-Type := Reject
        }
    }
}

This rule depends on successful chain validation and a CA that assigns device-001 only to the enrolled laptop. It does not validate a certificate by comparing an untrusted name alone. A valid certificate with a different common name must still be rejected by this rule.

For more devices, replace the one-device condition with a maintained authorization lookup that compares verified certificate attributes with enrollment records. Include the issuer when the same identifier can appear under several issuers. Disabling a device in those records should cause a new full authentication to fail even if its certificate has not expired.

Do not grant access based solely on the outer EAP username, the identity sent before the TLS exchange. EAP-TLS does not authenticate that username. The server may use it to route the conversation, but the device's permission must come from verified credentials and the authorization policy.

Make the Laptop Validate the RADIUS Server

Configure the supplicant for EAP-TLS with its enrolled certificate and key. Require the intended server name as well as the approved server CA. Trusting the CA without a name restriction can admit another server certificate issued by that CA.

For a Linux wpa_supplicant profile, the following fields belong inside the existing WPA2-Enterprise network block for Corp-Cert. The files must already exist at these paths:

eap=TLS
identity="device-001"
ca_cert="/etc/wifi/radius-server-ca.pem"
domain_match="radius.auth.example.com"
client_cert="/etc/wifi/device-001.pem"
private_key="/etc/wifi/device-001.key"

The laptop's server-CA file supplies the trusted issuing certificates for checking the RADIUS server. FreeRADIUS uses the client-CA file to check laptop certificates, so the two files serve separate purposes. Use the supplicant's protected credential handling for any encrypted-key passphrase.

In this profile, domain_match requires the full server name, without accepting subdomains or wildcard matches. A broad domain suffix would allow more names than this one-server example needs. On managed platforms with graphical settings, deploy the CA and permitted server names in the Wi-Fi profile and prevent users from accepting an unexpected server.

Test Authentication through the AP

Check the server configuration before restarting the service. On a package whose executable is freeradius, the configuration check is:

freeradius -XC

Read the reported errors and note any checks the command skips. A clean configuration check does not prove that a laptop can authenticate. For a controlled diagnostic session, run freeradius -X with the normal service stopped so the two processes do not compete for the listener; some packages name the executable radiusd.

Attempt a fresh connection through the actual AP and follow the matching exchange in server and client logs without sharing private keys or sensitive enrollment details. For the initial certificate tests, confirm that enable = no is set in the cache subsection of tls-common. Without TLS session resumption, a new EAP-TLS exchange must complete a full handshake and verify the certificate again.

The laptop using the enrolled device-001 certificate, matching key, and approved server CA and name should authenticate with EAP-TLS. FreeRADIUS should send Access-Accept to the AP, which should complete the laptop's connection.
A client certificate issued by an untrusted CA should fail certificate validation and be denied network access.
An expired client certificate should be denied during a fresh full authentication.
A valid client certificate outside the enrollment rule should be rejected by the authorization policy.
A server certificate from an untrusted CA, or with DNS SAN entries that do not include the permitted server name, should be rejected by the laptop, preventing the connection.

Perform negative certificate tests on the isolated test service, not by substituting an invalid certificate on a production RADIUS server. A client that rejects the server may abort the conversation before FreeRADIUS returns an Access-Reject, so use the client's validation error as evidence alongside the server log.

Authentication Ends before IP Configuration

After successful authentication, check the laptop's assigned network, IP address, gateway, and intended application access separately. DHCP supplies automatic IP settings after the laptop joins the network. An Access-Accept followed by a DHCP failure points to that later stage and does not justify weakening the certificate checks.

Success with PEAP, a method that can carry password authentication inside TLS, does not verify this certificate authentication setup. Confirm that the observed method is EAP-TLS and that the enrolled client certificate was evaluated.

Renew Credentials and Remove Lost Devices

Renew the laptop certificate before it expires and deliver the replacement through the enrollment process. Confirm that the renewed certificate still identifies the authorized device, has the required purpose, and works in a fresh full connection. Retire the old credential according to your key and certificate policy.

If the server's issuing CA changes, deploy the new trusted CA certificates to clients before switching the server certificate. Preserve the intended server name restriction. Test the replacement with the same Wi-Fi profile rather than assuming that adding a CA elsewhere on the laptop also changes that profile.

For a lost laptop, remove its permission from check-eap-tls or disable its entry in the fleet authorization lookup, and revoke its certificate. A certificate revocation list (CRL) lists revoked certificates; the Online Certificate Status Protocol (OCSP) lets a verifier request a certificate's status. If FreeRADIUS uses either method, ensure the checker receives current information and rejects the revoked credential; recording a revocation at the CA alone does not update the verifier.

Also test the removal with a fresh authentication. A cached TLS session or an already authorized wireless association can outlive the credential change. Set reauthentication and cache policy to the removal delay your organization can accept, and use the AP's supported session-disconnect mechanism when an existing association must end immediately.