After upgrading a ClearPass cluster from 6.11.11 to 6.12, multiple customers ran into an issue where a significant number of clients could no longer authenticate using EAP-TLS.

The environment:

• Certificates distributed via Microsoft Intune
• WiFi profiles also deployed through Intune
• Clients previously authenticated without issues against ClearPass 6.11.11

Immediately after the upgrade to 6.12, authentication failures started appearing in the Access Tracker with the following error:

Error code 215  
EAP-TLS: fatal alert by server - handshake_failure no suitable signature algorithm

First Thoughts: RSA-PSS

There are several posts online pointing toward RSA-PSS as the root cause. ClearPass 6.12 introduces changes in TLS handling, and the commonly suggested fix is:

Disable the TLS feature “Disable RSA-PSS Signature Suite in EAP-TLS”
(RADIUS Service Parameters → per ClearPass server)

So I did exactly that — set it to TRUE.

Unfortunately, this made things worse. After disabling RSA-PSS, none of the clients were able to authenticate anymore.

Time to dig deeper.

What Changed in 6.12? TLS 1.3.

Comparing authentication attempts between the old and new ClearPass servers revealed something important:

• ClearPass 6.11 → EAP using TLS 1.2
• ClearPass 6.12 → EAP using TLS 1.3

Starting with ClearPass 6.12, support for TLS 1.3 for EAP-TLS and PEAP (RFC 9190) was introduced.

Cluster-wide TLS 1.3 behavior is configurable under:

Administration → Server Manager → Server Configuration → Cluster Wide Parameters

You’ll find the following options:

• Network (Default after upgrade): Disables TLS 1.3 for EAP and enables HTTPS 1.3 on all servers in the cluster. On new ClearPass installations this is the default setting. When an existing ClearPass server is upgraded from an earlier version to 6.12.0, this is the default setting after upgrade.
• Admin: nables TLS 1.3 for EAP and the network, and disables TLS 1.3 for HTTP only, on all servers in the cluster. The Admin setting must be used in cases where client certificate-based authentications with SSO, OnGuard, or downloadable user roles are configured, as those do not work with TLS 1.3. Having the Admin setting as the default for upgraded servers ensures that if any of those configurations are present, the TLS setting will not interfere with them.
• All: Disables TLS 1.3 for EAP on all servers in the cluster. To support CC mode, the All option is required.
• None: Enables TLS 1.3 for EAP on all servers in the cluster. When the None option is enabled, TLS 1.3 is used as the preferred connection for systems that support it.

The TPM Angle

Buried in the 6.12 release notes is an important remark:

If a Trusted Platform Module (TPM) certificate with firmware version 1.16 is used and does not properly support the RSA-PSS algorithm, authentications fail.

In other words:

• Older TPM firmware versions do not correctly support RSA-PSS.
• TLS 1.3 prefers RSA-PSS.
• Result: authentication failure with “no suitable signature algorithm”.

Source:
https://arubanetworking.hpe.com/techdocs/ClearPass/CP_ReleaseNotes_6.x.x/Content/ReleaseNotes/NewFeatures/NewFeatures-6.12.0.htm

What Finally Fixed It

In my case, the combination that resolved the issue was:

1. Disable TLS 1.3 for Network (fallback to TLS 1.2)
2. Disable RSA-PSS Signature Suite

After applying both changes:

• Clients fell back to TLS 1.2 (confirmed in Access Tracker)
• Devices with older TPM firmware versions authenticated successfully
• EAP-TLS stability was restored

Takeaways

If you experience EAP-TLS failures after upgrading to ClearPass 6.12, check the following:

Check the following:

• Are clients using TPM-based certificates?
• What TPM firmware versions are in use?
• Is TLS 1.3 enabled for EAP?
• Is RSA-PSS enabled or disabled?

TLS 1.3 is a good step forward, but in mixed environments with older hardware TPM implementations, it can introduce compatibility issues.

Until TPM firmware is updated across the estate, falling back to TLS 1.2 may be the most pragmatic solution.

The following two tabs change content below.

• Bio
• Latest Posts

René Jorissen

Co-owner and Solution Architect at QMonkeys

René Jorissen works as Solution Architect for QMonkeys in the Netherlands. Network Infrastructures are the primary focus. René works with equipment of multiple vendors, like HPE Networks, FortiNet, SentinelOne, Phished, Holm Security, Microsoft services and many more. René is Aruba Certified Edge Expert (ACEX #26), Aruba Certified Mobility Expert (ACMX #438), Aruba Certified ClearPass Expert (ACCX #725), Aruba Certified Design Expert (ACDX #760), CCNP R&S, FCNSP and Certified Ethical Hacker (CEF) certified. You can follow René on Twitter and LinkedIn.

Latest posts by René Jorissen (see all)

• ClearPass 6.12 EAP-TLS Authentication Issues – “No Suitable Signature Algorithm” - February 11, 2026
• Aruba AOS 10 and Mesh Networking - January 28, 2026
• Deploy HPE 9106 gateways - January 20, 2026