12508 EAP-TLS handshake failed

[InfraISE2020]

Hi,

We upgraded from 2.7 - 3.0 and then a few weeks ago from 3.0 to 3.1 (for some AzureAD functionality that we require) but since the upgrade we are now seeing devices get rejected from the corporate network with the errors below:

Event 5400 Authentication failed
Failure Reason 12508 EAP-TLS handshake failed
Resolution Check whether the proper server certificate is installed and configured for EAP in the System Certificates page ( Administration > System > Certificates > System Certificates ). Also ensure that the certificate authority that signed this server certificate is correctly installed in client's supplicant. Similarly, verify that the certificate authority that signed the client's certificate is correctly installed in the Trusted Certificates page (Administration > System > Certificates > Trusted Certificates). Check the previous steps in the log for this EAP-TLS conversation for a message indicating why the authentication failed. Check the OpenSSLErrorMessage and OpenSSLErrorStack for more information.
Root cause EAP-TLS handshake failed.

OpenSSLErrorMessage SSL alert: code=0x233=563 ; source=local ; type=fatal ; message="decrypt error.ssl/statem/statem_lib.c:561 error:1417B07B:SSL routines:tls_process_cert_verify:bad signature [error=337096827 lib=20 func=379 reason=123]"
OpenSSLErrorStack 140056563922688:error:0407E086:rsa routines:RSA_verify_PKCS1_PSS_mgf1:last octet invalid:crypto/rsa/rsa_pss.c:88:

Has anyone come across this issue before? We have a ticket open with TAC but it doesn't appear to be getting anywhere near being resolved... This is a major issue for us as users cannot authenticate. 

Thanks in advance.

[Mike.Cifelli]

We upgraded from 2.7 - 3.0 and then a few weeks ago from 3.0 to 3.1

-I am assuming eap-tls onboarding was working fine before both bundle upgrades? Any other changes occur from ISE and/or client perspective? Is the CA chain that is presented in the client certs during onboarding in the ISE trust store? Are there any issues with validity for the ISE identity certs used for eap? Have you attempted to re-import the CA chain/s into trust store? Keep us posted with what TAC presents to you.

[InfraISE2020]

Hi @Mike.Cifelli 

EAP-TLS was working fine on both versions prior to the upgrade, this only appears to be an issue with version 3.1. 

Yep, the rootCA is stored in trusted certificates and has the same cert on the client.

Other model laptops appear to be ok, ours seems to be affecting surface tablet 4 devices.

TAC believe their is other known cases regarding TPM 2.0 and windows compatibility, have you come across this yet? 

I'm not sure how close you are to TAC but the experience has been painful thus far. 

[gizzard_man]

any updates here? we are running into the same and getting the same line from TAC. they have some registry keys that can be removed (looks like they got their info from https://docs.microsoft.com/en-us/answers/questions/467673/windows-10-tpm-20-client-authentication-in-tls-12.html ) and looks to "fix" the issue for us but not comfortable removing these keys on our clients for fear of impacting other TLS traffic

[Marcelo Morais]

Hi @InfraISE2020 ,

 IMO, the best way to help TAC on this is to install an ISE 3.0 Node to test an specific Endpoint & NAD with not only this ISE 3.0, but also with your ISE 3.1.... this way you have the possibility to easily compare both version.

Hope this helps !!!

[nir-r]

Hi

If you are using Anyconnect as 802.1x supplicant, try to upgrade to Anyconnect to the latest version (4.10.04071+)

[Marcelo Morais · Accepted solution]

Hi @nir-r ,

 didn't know ... thanks for that !!!

Hi @InfraISE2020 ,

 as @nir-r said ... also take a look at:

CSCvz90541 NAM: AnyConnect NAM 4.9.x/4.10.x fails auth w/ISE 3.1, but is successful with previous ISE versions

Symptom:
AnyConnect NAM 4.9.x/4.10.x fails to auth with ISE 3.1, but is successful with previous ISE versions

Conditions:
Specific to AnyConnect/NAM versions 4.9.x/4.10.x with ISE 3.1

Workaround:
1. Use AnyConnect/NAM 4.8.x - Not recommended but can be an option

2. Use Microsoft Native Supplicant

3. Use AnyConnect 4.9.x/4.10.x with ISE 2.7 or 3.0

Further Problem Description:
Behavior is currently being address via an ISE 3.1 patch.

Last Modified:
Feb 18, 2022.

Regards

[christian.faessler]

We had the very same problem, using the Windows 10 WiFi supplicant. So, this is not a real workaround for this problem.

But I was able to resolve the situation with the instructions from this page: https://learn.microsoft.com/en-us/answers/questions/467673/windows-10-tpm-20-client-authentication-in-tls-12.html

Basically, you only have to disable the RSA PSS cipher in the registry on the client.You can disable RSA PSS by following those steps:

• Start the registry
• Go to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003
• Backup/export this key
• Remove the following signature suites from 'Functions'
  - RSAE-PSS/SHA256
  - RSAE-PSS/SHA384
  - RSAE-PSS/SHA512
• Reboot

[DKCisco]

Hopefully Microsoft rolls out an update. This doesn't scale for my operation.

[Filippo Carzaniga]

I confirm that the issue is still present also with ISE version 3.2 patch 5.

Server Hello to PC with PSS Algorith:

Server hello to PC without PSS Algorithm:

Workaround: Azure Policy to disable Signature Algoritym RSAE-PSS.

[DKCisco]

Two years later I'm here reading this forum post and see that you had a problem we are experiencing now. The nam client is not installed on the workstations having this issue. Did you ever find a good solution for this?

[gizzard_man]

TPM Firmware updates on the devices having the issue. TPM 2.0 spec 1.38 or higher was required. The devices having this issue had a TPM 2.0 spec version below 1.38. Anything 2.0 spec 1.38 and above was fine.

Powershell to check version:

Get-CimInstance -Namespace "root\cimv2\security\microsofttpm" -class "win32_tpm"

[LAN team]

Hello,

Solution which has solved issue on my side on 3.1 version, choose 33/disable RSA_PSS signature  :

ISEPSN01/admin# application configure ise

Selection configuration option
[1]Reset M&T Session Database
[2]Rebuild M&T Unusable Indexes
[3]Purge M&T Operational Data
[4]Reset M&T Database
[5]Refresh Database Statistics
[6]Display Profiler Statistics
[7]Export Internal CA Store
[8]Import Internal CA Store
[9]Create Missing Config Indexes
[10]Create Missing M&T Indexes
[12]Generate Daily KPM Stats
[13]Generate KPM Stats for last 8 Weeks
[14]Enable/Disable Counter Attribute Collection
[15]View Admin Users
[16]Get all Endpoints
[19]Establish Trust with controller
[20]Reset Context Visibility
[21]Synchronize Context Visibility With Database
[22]Generate Heap Dump
[23]Generate Thread Dump
[24]Force Backup Cancellation
[25]CleanUp ESR 5921 IOS Crash Info Files
[26]Recreate undotablespace
[27]Reset Upgrade Tables
[28]Recreate Temp tablespace
[29]Clear Sysaux tablespace
[30]Fetch SGA/PGA Memory usage
[31]Generate Self-Signed Admin Certificate
[32]View Certificates in NSSDB or CA_NSSDB
[33]Enable/Disable/Current_status of RSA_PSS signature for EAP-TLS
[34]Check and Repair Filesystem
[35]Enable/Disable/Current_status of Audit-Session-ID Uniqueness
[0]Exit

[DKCisco]

Unfortunately, I’m still seeing the bug impact machines as they re-authenticate. I rebooted the psn nodes to make sure and it persists after the cli change as well as the reboot. The only thing that has worked as far as I can tell is doing a registry change on the workstation itself but that doesn't scale for us.

[LAN team]

The registry change at endpoint side or the RSA_PPS disabling on PSN side have the same effect, then I guess if any of these methods is solving your issue, you're not hitting this bug.