Certificate Validation in WPA2-Enterprise with RADIUS

In WPA2-Enterprise with RADIUS authentication, server certificate validation occurs through a certificate chain validation mechanism and matching of domain names or IP addresses. Clients automatically verify that the certificate from a trusted CA (such as Let’s Encrypt) matches the specified server, and if the certificate contains an IP address or domain name that doesn’t match what the client is connecting to, the connection will be blocked.

Contents

• How Certificate Validation Works in WPA2-Enterprise
• The Role of Domain Names and IP Addresses in Validation
• Protection Against Rogue Access Points
• Different EAP Methods and Certificate Requirements
• Practical Recommendations for Secure Configuration

How Certificate Validation Works in WPA2-Enterprise

When a client connects to a WPA2-Enterprise network, an EAP authentication process occurs, which includes verification of the RADIUS server certificate. This critical security step protects against Man-in-the-Middle attacks.

The certificate validation process includes several steps:

1. Trust chain verification: The client verifies that the certificate is issued by a trusted Certificate Authority (CA). In your case, Let’s Encrypt is a trusted CA for most modern devices.

2. Expiration check: The client ensures that the certificate is not expired and is valid at the current time.

3. Name matching verification: This is where the key check occurs - the client compares the name in the certificate with the name of the server it is connecting to.

It’s important to note that according to research, without proper server certificate validation, WPA2-Enterprise is not secure. Clients must ensure that devices authenticate RADIUS server certificates to protect against exploitation of fake SSIDs.

In your case, if clients are successfully connecting and seeing the certificate as trusted, it means that either:

• The certificate contains your server’s IP address in the Subject Alternative Name (SAN) field
• Or the client is configured to accept certificates without strict name verification

The Role of Domain Names and IP Addresses in Validation

This is a key point that causes confusion. When only the IP address of the RADIUS server is specified in the access point settings but not a domain name, certificate validation works as follows:

Name Matching Verification

The client compares the name in the certificate with the address of the server it is connecting to. The comparison is made against different certificate fields:

1. Common Name (CN) - the primary name in the certificate
2. Subject Alternative Name (SAN) - additional names that may include IP addresses and domain names

If only an IP address is specified in the SSID settings (for example, 192.168.1.100), then for successful certificate validation, it is necessary that:

• The certificate’s SAN field contains this IP address
• Or the client is configured to ignore name mismatches (which reduces security)

Example of a correct certificate for an IP address:
Subject Alternative Name: DNS:radius.yourdomain.com, IP Address:192.168.1.100

Why This Works in Your Case

In your case, Let’s Encrypt most likely generated a certificate for a domain name (for example, radius.yourdomain.com), but:

• This domain resolves to your server’s IP address
• Or your server’s IP address is included in the certificate’s SAN
• Or the clients are configured with a lower level of security verification

According to research, EAP-PEAP uses username/password authentication and requires that the device accepts or trusts the RADIUS certificate, so in your scenario, the system may work without strict name matching.

Protection Against Rogue Access Points

The protection mechanism against rogue access points with the same SSID and fake RADIUS server is based on several security layers:

1. Server Certificate Verification

When a client tries to connect to a rogue access point, it verifies the RADIUS server certificate. If:

• The certificate is issued by Let’s Encrypt but for a different domain
• Or the IP address doesn’t match what is expected
• Or the certificate doesn’t contain the correct name in the SAN

Then the client will reject the connection with a certificate error message.

2. Shared Secret

Access points and RADIUS servers use a shared secret for signing requests. An attacker, even by running a fake RADIUS server, won’t know this secret and won’t be able to properly authenticate requests from access points.

3. Client Certificate Verification (when using EAP-TLS)

In more secure configurations with EAP-TLS, client certificates are also verified, which provides mutual authentication.

As noted in research, proper client configuration ensures that devices authenticate RADIUS server certificates, which protects the EAP authentication process and prevents exploitation of fake SSIDs.

Different EAP Methods and Certificate Requirements

There are several EAP methods with different certificate requirements:

EAP-PEAP (Protected EAP)

• Requires: Only a server-side certificate
• Authentication: User through username/password
• Certificate verification: Client must trust the server certificate
• In your case: Most likely this method is being used

EAP-TLS (Transport Layer Security)

• Requires: Certificates on both server and client sides
• Authentication: Mutual through certificates
• Certificate verification: Strict name matching verification
• Security: Highest level of protection

PEAP (Protected EAP)

• Requires: Only a server-side certificate
• Authentication: User through username/password
• Certificate verification: Includes domain name verification

As explained in sources, EAP-PEAP uses username/password authentication, which only requires a RADIUS certificate that the device must accept or trust.

Practical Recommendations for Secure Configuration

To improve the security of your WPA2-Enterprise network, we recommend:

1. Configure Strict Certificate Verification

In wireless network profiles on clients, ensure that the option for verifying certificate name matching is enabled:

• For Windows: In wireless network properties → Security tab → Settings → Require server name verification
• For Android/iOS: In network profile settings, enable strict certificate verification

2. Use IP Addresses in SAN Certificates

If IP address is used in RADIUS server settings, ensure that this IP is included in the certificate’s SAN:

# Example of generating a certificate with IP in SAN
openssl req -new -x509 -key server.key -out server.crt -days 365 \
  -addext "subjectAltName = IP:192.168.1.100"

3. Monitor and Update Certificates

Regularly check:

• Certificate expiration dates
• Name matching in certificates
• Revocation of invalid certificates

4. Use Internal PKI for Critical Systems

For maximum security, consider using an internal PKI instead of Let’s Encrypt, which will allow:

• Issuing certificates only for required servers
• Controlling the trust chain
• Implementing stricter validation policies

As noted in research, without proper server certificate validation, WPA2-Enterprise is not secure, as it makes EAP traffic capture trivial for an attacker.

Sources

1. Configuring RADIUS Authentication with WPA2-Enterprise - Cisco Meraki Documentation
2. Without Server Certificate Validation, WPA2-Enterprise Isn’t Secure - SecureW2
3. RADIUS Authentication with WPA2-Enterprise - Cisco Community
4. WPA2 Enterprise: To Cert or Not to Cert? - Reddit
5. Certificate Based Wifi Authentication With RADIUS and EAP-TLS - SmallStep
6. Understanding RADIUS, TLS, and EAP-TLS for Network Security - SecureW2
7. Configure RADIUS Clients | Microsoft Learn
8. How Does a RADIUS Client/Supplicant Validate an Authentication Server? - Reddit

Conclusion

1. Certificate validation in WPA2-Enterprise occurs automatically through a trust chain validation and name matching mechanism, which protects against Man-in-the-Middle attacks.

2. IP address matching is ensured through the Subject Alternative Name field in the certificate, where the IP address of the RADIUS server used in the SSID settings should be specified.

3. Protection against rogue access points is achieved through server certificate verification, a shared secret between access points and RADIUS, and the possibility of mutual authentication.

4. The security of your configuration depends on whether clients are configured for strict certificate name matching verification. If clients accept certificates without name verification, this creates a vulnerability.

5. Recommended actions to improve security: enable strict certificate verification on clients, ensure the IP address is specified in SAN, consider transitioning to EAP-TLS for maximum protection.