Problem

The customer service desk reported a Windows computer could not authenticate to their network, neither wired or wireless. The issue did not affect all computers, and there were no obvious network configuration changes.

After checking the Clearpass access tracker, we could see the following error:

Error Code: 215
Error Category: Authentication failure
Error Message: TLS session error

Alerts for this Request:
EAP-TLS: fatal alert by client - access_denied
eap-tls: Error in establishing TLS session

The incident was initially troubleshooted by the workplace team, were they determined that this was a network issue.

Environment

  • Vendor: HPE
  • Platform: Clearpass Policy Manager
  • Software version: 6.11.9
  • Client: Windows 11

Troubleshooting

The initial investigation focused on looking through the logs in the Clearpass access tracker, where we could see the failed authentication request. The error indicated a client-side TLS failure and we could not see the client supplied certificate in the logs.

Having encountered a similar problem at other customers previously, we suspected it could be related to RSA-PSS compatibility, since this is known issue with some Windows devices using TMP certificates, and is documented bu HPE as CP-49353.

In this case, the hypothesis was tested by disabling RSA-PSS on the Clearpass side, which cause the next authentication request to be successful.

Root Cause

The observed authentication failure was consistent with a known RSA-PSS compatibility issue affecting certain Windows implementations.

Starting with Clearpass version 6.11, the implementation of OpenSSL was updated to support negotiating RSA-PSS signatures in EAP-TLS. Certain TPM implementations, particularly TPM 2.0 specification revision 1.16, cannot correctly perform the required RSA-PSS signing operation.

According to HPE’s documentation for CP-49353, affected Windows clients may send an invalid signature consisting of zeros in the TLS 1.2 Certificate Verify message. The TLS handshake subsequently fails.

The important distinction is that the client certificate itself is not necessarily invalid. The problem can instead be the TPM’s inability to perform the negotiated cryptographic operation.

Solution

ClearPass provides a server-side workaround for this compatibility issue, introduced in version 6.11.4, which prevents the affected RSA-PSS algorithms from being negotiated, allowing compatible alternatives to be used instead.

Note: This is a compatibility workaround rather than a fix for the underlying TPM implementation. It also requires consideration if using EAP-TLS with TLS 1.3, which requires RSA-PSS support in ClearPass. The preferred long-term solution is to updated the TPM firmware and fix the underlying issue.

Navigate to:

Administration → Server Manager → Server Configuration

  1. Select the ClearPass server.
  2. Open the Service Parameters tab.
  3. Select RADIUS server.
  4. Locate the TLS section.
  5. Change Disable RSA-PSS Signature Suite in EAP-TLS from FALSE to TRUE.
  6. Save the configuration.

If running a ClearPass cluster, apply the setting to the relevant RADIUS nodes.

Verification

After changing the ClearPass RADIUS server setting:

  • The affected Windows computer could connect to the network.
  • The authentication completed without the previous TLS session error.
  • No changes were required to the client certificate or Windows 802.1X configuration.

The workaround resolved the immediate issue.

Notes

Why did the problem appear now?

Potential triggers include a ClearPass upgrade (which I’m pretty sure I didn’t do), Windows updates, certificate renewal or changes to the client’s cryptographic configuration.

In this case, the exact trigger remains unknown, but something on the client side.

Future compatibility – ClearPass 6.14

ClearPass 6.14 enables TLS 1.3 by default. Since RSA-PSS is required for RSA-based TLS 1.3 authentication, the workaround described in this article is not compatible with that authentication combination.

Administrators planning to upgrade should investigate affected TPM implementations and resolve their compatibility issues before enabling EAP-TLS with TLS 1.3.

References:

Final observation:

The problem was caused by an apparent client-side cryptographic compatibility issue.

The solution was implemented on the network authentication infrastructure.

Therefore, according to established IT rules of placing blame, this was indeed a network issue.