Key Takeaways
- The “peer failed to perform TLS handshake” indicates that the TLS exchange was stopped before the endpoints could complete certificate authentication and establish session keys.
- When the error occurs in EAP-TLS, certificate trust, validity or protocol configuration are the common culprits rather than network reachability.
- Checking the TLS alert code in the log reveals what check failed and which side rejected the connection.
In RADIUS logs, the error “peer failed to perform TLS handshake” shows up when an EAP-TLS exchange stops before the client and server finish establishing a secure session.
Whether this error appears in FreeRADIUS, a Windows NPS log or a cloud RADIUS dashboard, the underlying issue is at the certificate or protocol layer, not the network layer.
This guide covers known root causes of this error across EAP-TLS and 802.1X authentication, with steps to identify and fix 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
- 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.
See your security gap before attackers do.
See continuous trust in action on a platform that includes RADIUS, PKI and AI security.
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.
Note: 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 using TLS 1.2:
- Client initiates network access: The supplicant (client device) and authenticator (such as a switch or wireless access point) begin the EAP exchange. An EAPOL-Start frame may be used to initiate the process.
- Server requests the client’s identity: The authenticator sends an EAP-Request/Identity to the supplicant, either directly or after receiving the request from the EAP server through RADIUS. The RADIUS server carries EAP messages in RADIUS packets when RADIUS is used.
- Client sends its identity: The supplicant responds with EAP-Response/Identity. This identity is typically used for routing or selecting an authentication method and does not necessarily have to match the identity in the client’s certificate.
- EAP-TLS begins: The EAP server sends an EAP-Request/EAP-TLS message with the Start (S) bit set. The authenticator relays it to the supplicant. The supplicant responds with an EAP-TLS message containing a TLS ClientHello.
- Server authenticates to the client: The EAP server sends its TLS certificate and the other TLS handshake messages required by the negotiated TLS version. If mutual certificate authentication is being used, the server also sends a CertificateRequest. The supplicant validates the server’s certificate and verifies that the certificate is appropriate for the server’s identity and use.
- Client authenticates to the server: In response to the CertificateRequest, the supplicant sends its certificate and proves possession of the corresponding private key. The exact TLS messages differ between TLS 1.2 and TLS 1.3. In TLS 1.2, this includes ClientKeyExchange, CertificateVerify, ChangeCipherSpec and Finished; TLS 1.3 uses Certificate, CertificateVerify and Finished instead.
- Server validates the client certificate: The EAP server validates the client’s certificate chain and verifies that the certificate is trusted and authorized for EAP-TLS. Depending on the implementation and configuration, it may also check certificate revocation status using mechanisms such as CRLs or OCSP.
- Session keys are established: The EAP-TLS peer and server derive EAP keying material from the TLS exchange, including the Master Session Key (MSK). The MSK is made available to the authenticator for use in establishing the network’s session keys.
- Authentication succeeds: The EAP server sends an EAP-Success, carried through RADIUS as part of an Access-Accept when RADIUS is being used. The authenticator then permits the supplicant to access the network according to its configured policy.
The RADIUS protocol itself carries EAP over User Datagram Protocol (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 |
| System clock skew on the client | Valid certificate rejected; failures cluster on devices that were powered off | Cause 11 |
| Firewall, proxy, or TLS inspection | Failure follows the network path rather than the device | Cause 12 |
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 6273 and check the Reason Code field, which identifies the specific certificate validation failure.
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 mobile device management (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).
Warning: 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.
Want to ensure you got the basics of 802.1X down? Check out our introductory video:
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 crl2pkcs7 -nocrl -certfile /path/to/server-chain.pem | openssl pkcs7 -print_certs -noout
openssl s_client cannot read an EAP-TLS chain off the wire. The handshake is carried inside RADIUS attributes rather than exposed as a TLS listener on UDP/1812, and -starttls has no radius option. Read the chain out of the server’s PEM bundle instead. If the server also speaks RADIUS over TLS (RadSec, TCP/2083 per RFC 6614), you can query that listener live with openssl s_client -connect <radius-server-ip>:2083. Either way, more than one certificate should appear in the output — a bundle holding only the end-entity certificate is missing its intermediate.
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.
Note: For client certificates, push the renewed certificate to devices via MDM auto enrollment. Manual distribution does not scale and leads to recurring failures.
SecureW2 JoinNow Dynamic 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.
Warning: Do not permanently re-enable TLS 1.0 or 1.1 for EAP-TLS. RFC 8996 deprecates both and states that they MUST NOT be used, and TLS 1.0 remains exposed to the BEAST attack against its CBC implementation (CVE-2011-3389)..
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, Internet of Things (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).
Info: 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 Simple Certificate Enrollment Protocol (SCEP) or 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 does. 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.
Note: 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 or OCSP 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).
Understand the CRL vs. OCSP conversation with our video below:
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.
Note: 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.
Note: 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 and the full handshake carries certificates in both directions, so it is the Certificate messages that push an EAP-TLS exchange past the RADIUS fragment size..
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.
Cause 11: System Clock Skew on the Client
A certificate can be valid according to the RADIUS server but appear invalid to a client with an incorrect system clock.
Under RFC 5280, the validity period is defined by the notBefore and notAfter pair. The certificate validator checks those timestamps against its local system time.
This can affect devices that have been offline for an extended period of time, such as laptops that have been powered off for months, have lost their real-time clock battery, or were recently imaged and have not yet synchronized with a time source.
The client can reject a valid RADIUS server certificate and generate the same fatal alert associated with an expired certificate.
Diagnosis
Check the failing client’s time against both the RADIUS server and a trusted time source. Even a few minutes of clock skew can matter when the certificate validity periods are short.
- Windows: Review the time service and confirm which time source the system is using.
- macOS and Linux: Confirm that the network time service is active and that the system reports successful synchronization.
Resolution
Configure all enrolled device to use a reachable time source and include time synchronization in the onboarding process.
The common problem is a device that authenticates before reaching the time server. On an 802.1X network that restricts traffic until authentication is successful, the supplicant may be unable to sync its clock, thereby being unable to validate the server certificate needed to authenticate.
Provide a provisioning path that allows time synchronization before full 802.1X access is enforced fixes this.
Cause 12: Firewall, Proxy or TLS Inspection in the Path
A TLS inspection does not always travel directly between the systems involved. Firewalls, proxies and TLS inspection appliances can interrupt and exchange, causing the error even when the certificates are valid.
Inspection products terminate the original TLS connection and present the client with a certificate signed themselves. The client therefore validates that certificate instead of the one it was originally configured to trust. If the inspection root is not in the operating system (OS) trust store, or lacks the appropriate trust, the certificate check fails and the peer sends a fatal alert.
The failure path is different for 802.1X because RADIUS is not an HTTPS connection that a web proxy can terminate.
RADIUS authentication is carried over UDP on port 1812, with TLS exchange is carried inside EAP rather than being directly exposed to the network.
The issue here is usually transport breaking down. A firewall that drops fragmented UDP, rate-limits it or permits it in only one direction prevent the EAP exchange from completing, leaving the RADIUS server to report a handshake failure.
Diagnosis
The first step is to identify whether the issue moves with the device or follows the network.
Test the same device by authenticating it on a segment where no inspection occurs in the path. Success on that network but failure elsewhere tells you that the path is the problem instead of the certificates.
On the RADIUS server, verify that requests are reaching the server and arriving intact. A request that never arrives or comes incomplete, can produce the same log as a client that rejected the server certificate.
Resolution
RADIUS traffic should be excluded from inspection rather subjecting it to it. Allow the assigned UDP ports bidirectionally between the network access devices and RADIUS server. Check that stateful rules are not timing out the exchange between fragments.
If a general-purpose inspection proxy is still necessary for other types of traffic, deploy its root to managed devices through the same profile used for 802.1X trust settings. This keeps the relevant two trust stores aligned.
The security plan that scales with you.
Our solutions can scale from mid-market to global enterprises. Compare options and see how our solutions protect you from costly breaches and ensure peace of mind.
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 the 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 “Peer Failed to Perform TLS Handshake” Errors With Managed 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.
Note: While the individual fixes in this guide will resolve the immediate error, they will not prevent the next one.
Dynamic PKI and JoinNow Cloud RADIUS remove the manual PKI steps that lead to these errors
Dynamic PKI automates certificate issuance, renewal and revocation across managed and BYOD devices using MDM integrations with Intune, Jamf, Google Workspace, and Mosyle 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 no on-premises 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 Dynamic 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
Is a failed TLS handshake a client problem or a server problem?
It can be either. Both the client and server can terminate the exchange, and the resulting log message reads the same. The TLS alert code helps identify which side rejected the connection. For example, a client that rejects the server certificate may send unknown_ca or certificate_expired traveling from client to server. The server rejecting the client certificate may return bad_certificate or certificate_unknown. Always check which endpoint sent the alert before you modify any configuration.
Can a firewall or proxy cause this error?
Yes, and it is often overlooked during troubleshooting as these issues are easy to miss because they generate same fatal alert as a bad certificate. A firewall can block or fragment authentication traffic, while inspection appliances can intercept the connection and present its own certificate to the client resulting in the fatal alert. A useful way to tell is to check whether the failure follows the network path: the same laptop authenticates on one segment and fails on another.
Why does the handshake fail for only some devices?
When the handshake fails for only certain devices, the cause points towards an issue shared between the failing devices rather than the server. For example, clients missing an intermediate certificate may fail because they cannot retrieve or cache it. A trimmed cipher list fails only the legacy and embedded devices. Devices with an inaccurate clock can also fail certificate validation after being offline or left unsynchronized. Group the failures by what they have in common before you change the server configuration.
How can I check whether the certificate is the problem?
Before troubleshooting the network, verify the certificate. Review its validity dates, issuer, extended key usage and revocation distribution point. Then verify it against the correct trust bundle the other side is loading. The OpenSSL command sequence in the diagnosis section above covers the four checks. If both certificates check out, the fault isn’t in the certificate. The failure is more likely related to the path or in protocol negotiation.
Is this error related to my browser or device?
Yes, it can be but context matters. Desktop applications, browsers and command line tools can show the same error message when the client library cannot finish a TLS handshake. The common causes are a wrong clock, a trust store missing an intermediate or a TLS version the client has switched off. If the message comes from a RADIUS log instead, treat it as an authentication problem and refer to the relevant RADIUS-specific causes covered above.
