Key Points
- The "peer failed to perform TLS handshake" error in a RADIUS log means the EAP-TLS handshake terminated before authentication completed — most often because of a certificate trust, validity, or protocol configuration problem.
- There are 10 distinct root causes: unknown CA, incomplete certificate chain, expired certificate, TLS version mismatch, cipher suite mismatch, missing EKU, wildcard CommonName, CRL/OCSP failure, RSA-PSS/TPM signing issue, and MTU fragmentation.
- Fixing the immediate error is not enough. Recurring handshake failures in EAP-TLS environments trace back to manual certificate management — a problem that managed Cloud PKI eliminates.
The error “peer failed to perform TLS handshake” appears in RADIUS logs when an EAP-TLS authentication exchange terminates before the client and server finish negotiating a secure session. If you are seeing this error in FreeRADIUS, a Windows NPS log, or a cloud RADIUS dashboard, the handshake broke on the certificate or protocol layer, not the network layer.
This guide covers every known root cause of this error in EAP-TLS and 802.1X authentication contexts, with a diagnosis path and resolution for each one. A general SSL/TLS section at the end covers the browser and API gateway variants of the same error.
What Does ‘Peer Failed to Perform TLS Handshake’ Mean?
A TLS handshake is the opening negotiation between two endpoints before any application data is exchanged. Both parties agree on a TLS version and cipher suite, exchange certificates, and derive the session keys that will encrypt the connection. If either party cannot complete its part of that exchange, it sends a TLS alert and terminates the connection.
“Peer failed to perform TLS handshake” means the remote endpoint — the “peer” — sent a fatal TLS alert or dropped the connection before the handshake completed. In EAP-TLS authentication, the peer is usually the client device (supplicant), but it can also be the RADIUS server failing to present a valid server certificate to the client.
The error string most commonly comes from GLib-based TLS implementations, FreeRADIUS, and other applications using the GnuTLS or OpenSSL libraries to indicate a handshake failure. The underlying TLS alert code tells you which party failed and why, but the surface error message is the same regardless.
In an EAP-TLS context, this error almost always means one of two things: the client refused to trust the server certificate, or the RADIUS server refused to trust the client certificate. EAP-TLS has stricter requirements than standard HTTPS, meaning authentication failures are more common. We’ll address each of the above reasons individually in the next section.
How EAP-TLS Uses TLS, and Why It Fails Differently
EAP-TLS (Extensible Authentication Protocol — Transport Layer Security) is the most secure 802.1X authentication method. That security comes in part from a mutual TLS handshake inside the EAP tunnel: both the client and the RADIUS server must present and validate each other’s certificates before the RADIUS server issues an Access-Accept.
This mutual authentication requirement is what makes EAP-TLS both highly secure and more prone to handshake failures than standard one-way TLS. In HTTPS, only the server presents a certificate. In EAP-TLS, both parties do, and both sides must have correctly configured trust stores to validate the other.
This is the handshake sequence for EAP-TLS authentication:
- Client requests network access: The supplicant (client device) sends an EAP-Start to the network access device (AP or switch).
- RADIUS server requests identity: The authenticator (AP/switch) forwards the request to the RADIUS server, which responds with EAP-Request/Identity.
- Client sends identity: The supplicant responds with its identity (username or device name).
- RADIUS server initiates TLS: The server sends EAP-Request/TLS with a TLS ServerHello and presents its server certificate.
- Client validates the server certificate: The supplicant checks that the server certificate was issued by a trusted CA and that it is valid (not expired, not revoked, correct EKU).
- Client presents its certificate: The supplicant sends its client certificate in the TLS handshake.
- RADIUS server validates the client certificate: The server checks the client certificate against its trusted CA list, validates the chain, checks CRL/OCSP if configured, and verifies the EKU.
- Session keys are derived: Both parties derive the Master Session Key (MSK) from the TLS handshake.
- RADIUS server sends Access-Accept: Authentication succeeds and the network device grants access.
- Failure path: If either step 5 or step 7 fails, the failing party sends a TLS alert (typically unknown_ca, certificate_expired, bad_certificate, or handshake_failure), and the RADIUS server logs “peer failed to perform TLS handshake.”
The RADIUS protocol itself carries EAP over UDP, which adds one more complication. RADIUS packets are limited in size, and large certificate chains can be fragmented across multiple packets. Exchanges that work fine in HTTPS can become MTU issues over EAP-TLS, with little warning.
Quick-Reference Troubleshooting Table
Use this table to match your log message or symptom to the likely cause, then go to the corresponding section for diagnosis and resolution.
| Cause | Log Message / Symptom | Go To |
| Unknown or untrusted CA | TLS alert: unknown_ca/client rejects server cert | Cause 1 |
| Incomplete certificate chain | Handshake fails only on some clients | Cause 2 |
| Expired certificate | certificate_expired TLS alert | Cause 3 |
| TLS version mismatch | Failure after ClientHello; protocol_version alert | Cause 4 |
| Cipher suite mismatch | handshake_failure alert; no shared cipher | Cause 5 |
| Missing EKU | Auth fails with valid cert; ISE/NPS rejects client cert | Cause 6 |
| Wildcard CommonName | Auth fails for server cert check only | Cause 7 |
| CRL/OCSP failure | Intermittent failures; fails in “fail-close” environments | Cause 8 |
| RSA-PSS/TPM issue | All-zeros signature in handshake; Windows devices only | Cause 9 |
| MTU fragmentation | Failures on VPN/WAN-connected RADIUS only | Cause 10 |
If your log shows a different error, see How to Diagnose TLS Handshake Failures for commands to extract the specific TLS alert code.
Cause 1: Unknown or Untrusted Certificate Authority
This is the most common cause of a failed EAP-TLS handshake. Either the client does not trust the RADIUS server’s certificate authority, or the RADIUS server does not trust the client certificate’s CA.
In FreeRADIUS logs, this appears as: TLS Alert read:fatal:unknown CA. In Windows event logs, look for NPS Event ID 18 with “The client could not be authenticated because the certificate presented is not trusted.”
Diagnosis
On the client side, check which root CA certificates are in the device’s trusted store for 802.1X. On Windows, open certmgr.msc and look under Trusted Root Certification Authorities. On macOS/iOS, check the device profile in MDM for the trusted root payload. On Android, check Settings → Security → Trusted Credentials.
On the RADIUS server side, check the CA certificates loaded into the server’s trust store. In FreeRADIUS, these are specified in tls-config under ca_file or ca_path. Verify that the issuing CA for the client certificates is in that list.
Run the following to inspect what CAs a certificate chains to:
openssl verify -CAfile /path/to/ca-bundle.pem /path/to/client.pem
Resolution
If the client does not trust the server certificate, you should push the RADIUS server’s root CA certificate to the device trust store via MDM (Intune, Jamf, Google Workspace). Do not instruct users to accept untrusted certificates — this defeats the purpose of EAP-TLS.
If the RADIUS server does not trust the client certificate, add the issuing CA and any intermediate certificates to the RADIUS server’s trusted CA list. Restart the RADIUS service after updating.
Verify trust is configured for 802.1X specifically. Many operating systems require the trusted CA to be explicitly trusted for EAP/802.1X in the network profile, not just in the system root store.
Cause 2: Incomplete Certificate Chain
A certificate chain problem differs from one stemming from an unknown CA. The root CA may be trusted, but one or more intermediate certificates are missing from the presentation. When the RADIUS server or client presents only the end-entity certificate without the intermediate CA certificates, the other side cannot build the chain to the trusted root.
This commonly happens after certificates are renewed or reissued from a new intermediate CA.
Diagnosis
Inspect the certificate presented during the handshake. With OpenSSL use:
openssl s_client -connect <radius-server-ip>:1812 -starttls radius
This command is not universally supported by all RADIUS stacks, but where available it shows the full certificate chain presented. Look for “depth=1” entries — missing intermediates show as a chain with “depth=0” only.
In packet captures, look at the TLS Certificate message. If the server is sending a single certificate with no chain, the intermediate is missing.
Resolution
On the RADIUS server you should configure the server to send the full chain, including the intermediate CA certificate. In FreeRADIUS, set certificate_file to a PEM file that concatenates the server cert, intermediate, and root in that order.
On the client side, the client certificate deployed via MDM should include the full chain in the certificate payload, or the intermediate CA should be separately deployed as a trusted intermediate.
After updating, verify with the openssl verify command above that the chain resolves without errors.
Cause 3: Expired Client or Server Certificate
An expired certificate will trigger the certificate_expired TLS alert (alert code 45) on whichever side is validating the certificate. Server certificate expiry tends to fail all clients simultaneously, while client certificate expiry causes individual user or device failures.
Diagnosis
Check the certificate expiration date:
openssl x509 -in /path/to/cert.pem -noout -dates
For a deployed client certificate on Windows, open certlm.msc (Local Machine) or certmgr.msc (Current User) and sort by expiration date. For macOS, use Keychain Access and filter by certificate type.
In FreeRADIUS debug mode (radiusd -X), look for: TLS_accept: failed in Accept following an alert close notify or certificate_expired alert.
Resolution
Renew the expired certificate from the issuing CA. If using an internal PKI, reissue from the CA console.
For server certificates, update the RADIUS server configuration to point to the renewed certificate file and restart the service.
For client certificates, push the renewed certificate to devices via MDM auto-enrollment. Manual distribution does not scale and leads to recurring failures.
SecureW2 Cloud PKI handles certificate lifecycle automatically — tracking expiration dates and triggering renewal before certificates expire. Devices enrolled through the JoinNow platform receive renewed certificates without any user action.
Cause 4: TLS Version Mismatch
EAP-TLS requires TLS 1.2 or TLS 1.3. Older clients configured for TLS 1.0 or 1.1 will fail to negotiate with RADIUS servers that have disabled those versions. The handshake fails at the ServerHello stage with a protocol_version TLS alert (alert code 70).
This failure mode is common in environments that have hardened their RADIUS server to reject older TLS versions but have not updated supplicant configurations on legacy devices.
Diagnosis
In FreeRADIUS debug output, look for:
TLS_accept: error in Accept
SSL3_GET_CLIENT_HELLO:no shared cipher
Or, in the packet capture, look at the ClientHello — if the client’s highest TLS version is 1.1 and the server only accepts 1.2+, the ServerHello will be absent and the server will send an alert.
On Windows, check the registry for SSL/TLS protocol settings under: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Resolution
On legacy clients, update the TLS version in the wireless network profile or the supplicant configuration. On Windows, update the SCHANNEL registry keys or use the IISCrypto tool. On Android, supplicant TLS version is controlled by the EAP configuration in the network profile.
On the RADIUS server, if legacy client support is required, enable TLS 1.2 as the minimum while maintaining TLS 1.0/1.1 support on a temporary basis. Set a migration deadline and remove TLS 1.0/1.1 once clients are updated.
Do not permanently re-enable TLS 1.0 or 1.1 for EAP-TLS. Both are deprecated and subject to known vulnerabilities (POODLE, BEAST).
Cause 5: Cipher Suite Mismatch
If the client and server don’t share any cipher suites, the handshake fails with a handshake_failure alert (alert code 40). This differs from a TLS version mismatch — both sides may agree on TLS 1.2, but have incompatible cipher lists.
This error typically arises after RADIUS server hardening removes older cipher suites that some client operating systems still require. It also appears on some legacy hardware (embedded devices, older printers, IoT sensors) with limited cipher suite support.
Diagnosis
In FreeRADIUS debug mode, the failure appears after the ClientHello with a message indicating no shared cipher. Use OpenSSL to list what ciphers a server accepts:
openssl s_client -connect <server>:<port> -tls1_2 -cipher ‘ALL:@SECLEVEL=1’
Compare this against the cipher list in the ClientHello, which is visible in a Wireshark capture. Look for cipher suite overlap — if there is none, this is the cause.
Resolution
Identify the minimum required cipher suite for your client population. NIST SP 800-52 Rev. 2 provides approved cipher suite guidance for TLS 1.2 and 1.3.
Extend the RADIUS server’s cipher list to include at least the cipher suites required by the oldest clients that must authenticate.
For modern clients (Windows 10+, macOS 11+, iOS 14+, Android 10+), the default cipher suite list is compatible with TLS 1.2 and 1.3 server configurations. This issue almost always crops up on legacy or embedded device clients.
Cause 6: Missing Extended Key Usage (EKU)
Extended Key Usage (EKU) is a certificate extension that specifies what the certificate may be used for. For EAP-TLS client authentication, the client certificate must include the clientAuth EKU (OID 1.3.6.1.5.5.7.3.2). For server certificates, the RADIUS server certificate must include the serverAuth EKU (OID 1.3.6.1.5.5.7.3.1).
Many RADIUS implementations strictly enforce EKU checking. If a client certificate is missing clientAuth, authentication fails even if everything else is correct. The error may appear as a generic bad_certificate TLS alert or as a policy rejection in the RADIUS server log rather than a clear EKU message.
Diagnosis
Inspect the EKU field of the relevant certificate:
openssl x509 -in /path/to/cert.pem -noout -text | grep -A2 “Extended Key Usage”
For a client certificate, you should see TLS Web Client Authentication. For a server certificate, TLS Web Server Authentication. If either field is absent or shows only Code Signing or Email Protection, the certificate was issued with the wrong template.
In FreeRADIUS debug output, look for a rlm_eap_tls: Received EAP-TLS ACK message followed by authentication failure with no TLS alert. This can indicate an EKU policy rejection after the handshake technically completed.
Resolution
Reissue the certificate with the correct EKU. On a Microsoft CA, use a certificate template that has Client Authentication in the Application Policies extension. Do not use a certificate issued from a code signing or email template.
For managed devices, update the MDM certificate profile (Intune SCEP/PKCS, Jamf, etc.) to use a template that includes clientAuth EKU. Revoke and redeploy the affected certificates.
The Digital Signature Key Usage extension is also required for EAP-TLS client certificates. Confirm it is present alongside clientAuth EKU.
Cause 7: Wildcard Certificate in CommonName Field
EAP-TLS does not support wildcard certificates in the CommonName (CN) field of the RADIUS server certificate. A wildcard CN (e.g., *.example.com) is valid for HTTPS, but most EAP-TLS supplicants do not accept it.
The 802.1X supplicant performs server certificate validation differently than a browser. It checks whether the server’s CN or Subject Alternative Name (SAN) matches the configured RADIUS server name in the network profile. This process doesn’t include wildcards, so clients reject the server certificate and the handshake fails at step 5.
Diagnosis
Inspect the server certificate CN and SAN fields:
openssl x509 -in /path/to/server.pem -noout -subject -text | grep -A5 “Subject Alternative Name”
If the CN contains a * prefix, that is the problem. If the SAN entries contain wildcard DNS names, it may also be rejected depending on the supplicant.
Resolution
Replace the RADIUS server certificate with one that has the exact Fully Qualified Domain Name (FQDN) of the RADIUS server in both the CN and DNS SAN entry. For example: radius.example.com, not *.example.com.
Configure client network profiles to validate the server against this exact FQDN. In Intune, set the “Server Certificate Name” field in the Wi-Fi SCEP profile to match the RADIUS server CN exactly.
Do not use the same wildcard certificate for RADIUS and web services. Issue a dedicated certificate for the RADIUS server from your internal CA.
Cause 8: CRL/OCSP Validation Failure
RADIUS servers configured to check certificate revocation via CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol) will fail EAP-TLS handshakes when they cannot reach the revocation endpoint. This is a common problem in environments where the RADIUS server is hardened (“fail-close” mode) — it rejects authentication if revocation status cannot be confirmed.
The failure is often intermittent: it occurs during network outages, DNS failures, or when the CRL distribution point URL becomes unreachable (expired CRL, moved URL, firewall rule change).
Diagnosis
In FreeRADIUS, enable debug mode and look for CRL or OCSP fetch errors. Common messages are:
- SSL: error:0200100D:system library:fopen:Permission denied
- unable to get local issuer certificate
- CRL has expired
On Windows NPS, check the RADIUS server’s network connectivity to the CRL distribution point listed in the client certificate. The CDP URL is in the certificate:
openssl x509 -in /path/to/cert.pem -noout -text | grep -A3 “CRL Distribution”
Try fetching the CRL manually from the RADIUS server to confirm reachability:
curl -o /dev/null -v <CRL URL from certificate>
Resolution
If the RADIUS server cannot reach the CRL/OCSP endpoint, fix the network path and allow outbound HTTP (port 80) from the RADIUS server to the CRL distribution points. Internal PKI CRL endpoints must be accessible from the RADIUS server’s network segment.
If the CRL has expired, regenerate and republish the CRL from the issuing CA. Configure the CA to publish CRLs on a schedule that provides sufficient overlap before expiry.
A temporary workaround (fail-open) is to disable strict CRL checking in FreeRADIUS by setting check_crl = no in tls-config. This is appropriate for troubleshooting but not as a permanent production setting.
If using OCSP, confirm the OCSP responder URL is reachable and the OCSP responder certificate is valid.
Cause 9: RSA-PSS/TPM Signing Issue
Windows devices using TPM 2.0 with certificates stored in the TPM hardware may produce a TLS handshake signature that consists entirely of zero bytes. This is a known issue with how some TPM 2.0 implementations (specifically those using RSA-PSS padding) interact with certain versions of wpa_supplicant and RADIUS server TLS stacks.
The symptom is specific: the client certificate is presented correctly and the EKU is valid, but the CertificateVerify message in the TLS handshake carries an all-zero signature. The RADIUS server logs a decrypt_error or bad_certificate TLS alert.
This issue occurs primarily in deployments using Windows 10/11 TPM-backed certificates with FreeRADIUS versions that do not properly handle RSA-PSS signatures.
Diagnosis
Capture the EAP-TLS handshake with Wireshark and inspect the TLS CertificateVerify message. If the signature bytes are 00 00 00 00… padded to the key size, this is the TPM RSA-PSS issue.
In FreeRADIUS debug output, look for:
TLS_accept:error in Accept
SSL routines:ssl3_get_cert_verify:wrong signature type
Resolution
A FreeRADIUS workaround is to add tls_min_version = “1.2” and explicitly configure the RADIUS server to accept RSA-PSS signatures if running a version that supports it (FreeRADIUS 3.0.22+ has partial fixes).
Alternatively, a client-side workaround is to configure the Windows supplicant to use software-based key operations rather than TPM-backed operations for the authentication certificate. This can be done via MDM by issuing certificates to the Software key storage provider instead of TPM KSP.
No matter what fix you use, the long-term solution is to move to ECDSA certificates. ECDSA does not use RSA-PSS padding and doesn’t produce this TPM interaction problem. Reissue client certificates with EC key type.
Cause 10: MTU Fragmentation Over VPN or WAN
EAP-TLS handshakes involve large messages. Certificate chains can easily exceed 1,000 bytes, the full handshake includes multiple certificates, and the TLS finished message can be several kilobytes.
RADIUS carries EAP payloads, which have a fragmentation mechanism, over UDP. When the RADIUS server is separated from the network access device by a VPN or WAN link with a reduced MTU, EAP fragment reassembly can fail silently.
The symptom is that EAP-TLS authentication works on the local campus network but fails when authenticating through a branch RADIUS proxy or when the RADIUS server is in a cloud environment accessed over a VPN.
Diagnosis
Compare authentication behavior between clients on the same network segment as the RADIUS server and clients connecting through the VPN or WAN path. If the failure is path-dependent, MTU is the likely cause.
Measure the effective MTU between the network access device and the RADIUS server:
ping -M do -s 1400 <RADIUS server IP>
Reduce the payload size progressively until packets pass. If ICMP is blocked, use tcpdump on the RADIUS server to look for fragmented UDP packets that arrive incomplete.
Resolution
On the RADIUS server, reduce the EAP fragment size in FreeRADIUS. In eap.conf, set:
fragment_size = 1024. 1024 is the default; reduce to 512 if fragmentation problems persist over low-MTU links.
Adjust the network path MTU to avoid fragmentation. Set the ip mtu and ip tcp adjust-mss on the VPN or WAN interface on both ends of the link.
If using a RADIUS proxy in the branch, confirm it is reassembling EAP fragments correctly before forwarding to the home RADIUS server.
General SSL/TLS Context: Web Browsers and API Gateways
The “peer failed to perform TLS handshake” error also appears outside of RADIUS in GNOME applications (Evolution, Nautilus, Flatpak), API gateways, and mutual TLS service mesh configurations. The same root causes apply, but the diagnosis tools and resolution paths differ.
Common Non-RADIUS Causes
- System clock skew: TLS certificates are time-bound. If the client’s system clock is significantly off (>5 minutes), certificate validity checks fail. Sync the system clock via NTP.
- Outdated TLS configuration: Web servers configured to accept only TLS 1.3 may reject older clients. Update the server’s TLS configuration in nginx (ssl_protocols TLSv1.2 TLSv1.3;) or Apache (SSLProtocol TLSv1.2 TLSv1.3).
- Browser/OS TLS settings: Browsers that have TLS 1.2 or 1.3 disabled in their SSL settings will fail to connect to servers that require it. In Chrome, check chrome://settings/security. In Windows, check Internet Options → Advanced → Security.
- Missing full chain on server: Web servers that present only the end-entity certificate without the intermediate will cause handshake failures on clients that cannot resolve the chain from cached intermediates. Always configure the server with the full certificate chain (cert + intermediate).
Diagnostic command for web TLS:
openssl s_client -connect <hostname>:443 -servername <hostname>
Review the output for chain depth, certificate validity dates, supported TLS versions, and any TLS alert messages.
How to Diagnose TLS Handshake Failures
When the log message is insufficient to identify the cause, use these diagnostic approaches to extract the specific TLS alert code and failure point.
FreeRADIUS Debug Mode
Run FreeRADIUS in debug mode to get full TLS handshake output:
radiusd -X
Look for lines starting with TLS_accept or TLS Alert. The TLS alert code shows the cause:
| TLS Alert Code | Alert Name | Likely Cause |
| 42 | bad_certificate | Cert format error, missing EKU, or TPM signing issue |
| 44 | certificate_revoked | Certificate is on CRL or OCSP returns revoked |
| 45 | certificate_expired | End-entity or CA certificate has expired |
| 46 | certificate_unknown | General validation failure (chain, EKU, policy) |
| 48 | unknown_ca | Issuing CA not in trusted store |
| 70 | protocol_version | TLS version mismatch |
| 40 | handshake_failure | No shared cipher suite or general handshake failure |
Packet Capture with Wireshark
Capture traffic on the RADIUS server’s interface and filter for RADIUS packets:
tcpdump -i eth0 -w /tmp/radius.pcap udp port 1812
Open the capture in Wireshark and filter for eap. Inspect the TLS handshake messages — the Certificate message shows what certificates are being sent, and the Alert message shows the exact alert code and direction (client-to-server or server-to-client). The direction tells you which party is rejecting the other’s certificate.
Windows NPS Event Log
On Windows NPS, authentication failures are logged in the Security event log with Event ID 6273. The “Reason Code” field indicates the EAP failure type. Reason Code 22 corresponds to an incomplete EAP handshake — see our NPS Reason Code 22 troubleshooting guide for that specific case.
OpenSSL Certificate Inspection
For any certificate involved in the failure, this command sequence covers most diagnostic needs:
# Check validity dates
openssl x509 -in cert.pem -noout -dates
# Check issuer and subject
openssl x509 -in cert.pem -noout -issuer -subject
# Check EKU and Key Usage
openssl x509 -in cert.pem -noout -text | grep -A3 “Key Usage”
# Verify chain
openssl verify -CAfile ca-bundle.pem cert.pem
# Check for CRL distribution points
openssl x509 -in cert.pem -noout -text | grep -A3 “CRL Distribution”
For configuration guidance specific to FreeRADIUS and EAP-TLS, see the SecureW2 setup guide.
Eliminate Certificate Failures with Managed Cloud PKI
The various causes of a “peer failed to perform TLS handshake” message nearly all trace to the same underlying problem: certificates were issued manually, deployed manually, or managed without automation. Manual PKI operations create gaps, such as expired certificates that nobody caught, incomplete chains due to missing intermediates, or CRL endpoints that went stale.
While the individual fixes in this guide will resolve the immediate error, they will not prevent the next one.
SecureW2 Cloud PKI and JoinNow Cloud RADIUS negate the possibility of manual errors in PKI. Cloud PKI automates certificate issuance, renewal, and revocation across managed and BYOD devices — using MDM integrations with Intune, Jamf, Google Workspace, and Kandji to push correctly configured certificates to devices without manual steps. Every certificate issued through the platform carries the correct EKU, comes from a trusted root CA that is pre-deployed to devices, and is tracked for expiry with automated renewal.
Cloud RADIUS handles the server side. It operates as a cloud-hosted RADIUS service with TLS 1.2 and TLS 1.3 support, a valid server certificate from a managed CA, and means no on-premise infrastructure to misconfigure. When a device authenticates, Cloud RADIUS performs a real-time identity lookup against Entra ID, Okta, or Google Workspace — access is tied to user and device status, not a static certificate that may have been issued to a user who left the organization months ago.
If your team is troubleshooting recurring 802.1X certificate authentication failures, the root cause is almost always the manual PKI process, not the specific error message in the log.
Schedule a demo to see how SecureW2 Cloud PKI and Cloud RADIUS eliminate the certificate lifecycle problems that produce EAP-TLS handshake failures, or contact SecureW2 to discuss your specific deployment.
Frequently Asked Questions
What does "peer failed to perform TLS handshake" mean in FreeRADIUS?
In FreeRADIUS, this message appears when the EAP-TLS handshake between the RADIUS server and the client device (supplicant) terminates before completion. The most common causes are: the client's certificate authority is not in the server's trusted CA list, the server certificate is not trusted by the client, the client certificate is missing the clientAuth EKU, or the certificate has expired. Run radiusd -X and look for the specific TLS alert code to identify the cause
How do I check if a certificate is trusted by a RADIUS server?
On a FreeRADIUS server, the trusted CA certificates are specified in the tls-config section of eap.conf under ca_file or ca_path. To verify that a client certificate chains to one of those CAs, run:
openssl verify -CAfile /path/to/ca-bundle.pem /path/to/client.pem
If the output is not OK, the certificate chain cannot be verified against the configured CAs — this will cause authentication to fail.
What is EKU (Extended Key Usage) and why does it cause EAP-TLS authentication to fail?
Extended Key Usage is a certificate extension that specifies the permitted purposes for a certificate. EAP-TLS client authentication requires the clientAuth EKU (OID 1.3.6.1.5.5.7.3.2). RADIUS server certificates require serverAuth (OID 1.3.6.1.5.5.7.3.1). If a certificate is missing the required EKU — for example, because it was issued from a code signing template — the RADIUS server will reject it, even if the chain and expiry are valid. Inspect EKU with: openssl x509 -in cert.pem -noout -text | grep -A2 "Extended Key Usage"
Can I use a wildcard certificate with EAP-TLS for 802.1X authentication?
Not for the RADIUS server certificate. Most 802.1X supplicants do not resolve wildcard Common Names during server certificate validation. The supplicant checks that the server's CN or SAN matches the configured RADIUS server name in the network profile, and wildcards fail that match. Use a certificate with the exact FQDN of the RADIUS server in both the CN and a SAN DNS entry.
What TLS versions does EAP-TLS support?
EAP-TLS supports TLS 1.2 and TLS 1.3. TLS 1.0 and 1.1 are deprecated (RFC 8996) and should not be used. Most modern RADIUS servers (FreeRADIUS 3.0+, cloud RADIUS services) default to TLS 1.2 as the minimum. Older supplicants or embedded devices that only support TLS 1.0 or 1.1 will fail to authenticate against hardened RADIUS servers. Update the supplicant or operating system TLS configuration to support TLS 1.2.
How do I fix RADIUS authentication failures caused by MTU fragmentation?
Reduce the EAP fragment size on the RADIUS server. In FreeRADIUS eap.conf, set fragment_size = 1024 (or lower to 512 if problems persist). This limits individual EAP fragment payloads to fit within the available path MTU. Also check the VPN or WAN interface MTU and adjust with ip tcp adjust-mss if you can control the network path.
How do I prevent recurring "peer failed to perform TLS handshake" errors?
Recurring EAP-TLS failures almost always trace to manual certificate operations: certificates issued with wrong parameters, deployed without full chains, left to expire without renewal, or CRL endpoints that go stale. The long-term fix is automating the certificate lifecycle through managed PKI. SecureW2 Cloud PKI handles certificate issuance, renewal, and revocation automatically through MDM integrations — eliminating the manual steps that produce recurring EAP-TLS failures. See how it works at securew2.com/dynamic-pki.
