HiI have a customer affected by CP‑49353 in all 6.11.x versions (found in Policy manager section under Known Issues for 6.11.0 in the Release Notes) and got the information from the TAC that it's a client issue. The Windows client sends 256 zeroes instead of the sha256 hash.Have anyone else encountered this issue and are able to tell if the it's works good to disable RSA PSS algorithm on the Windows client, any other issues arising?I would also like to know is someone can explain why this is happening only when the clients connect to ClearPass 6.11.x and not earlier versions, like 6.10.x.Is there a change in the lowest possible algorithm in 6.11 and this forces the client to negotiate a an algorithm that is poorly implemented on the Windows side?The error message seen in Access Tracker is:
TLS session error
Alerts for this Request
EAP-TLS: fatal alert by server - decrypt_errorTLS Handshake failed in SSL_read with error:0407E086:rsa routines:RSA_verify_PKCS1_PSS_mgf1:last octet invalideap-tls: Error in establishing TLS session
OpenSSL version used in 6.10 and earlier did not have support for RSA PSS forcing ClearPass to negotiate a different cipher suite and hence this issue is not seen in older versions. 6.11 with its updated openSSL module negotiates RSA PSS but fails due to the implementation bug on Microsoft side. So far it seems like only devices with TPM 2.0 revision 1.16 has this issue. If the device supports TPM upgrade, that is one way to fix the issue. However TPM update is not an option in all cases. Work arounds are to disable RSA-PSS on windows client side or TPM update. If either these options doesn't work, TAC might be able to help disable TLS 1.2 from support shell.
------------------------------Best RegardsJonas HammarbäckMVP 2023, ACCX #1335, ACX-Network Security, Aruba SME, ACMP, ACDP , ACEP, ACSAAranya ABIf you find my answer useful, consider giving kudos and/or mark as solution------------------------------
Thank you for the answer!
OpenSSL version used in 6.10 and earlier did not have support for RSA PSS forcing ClearPass to negotiate a different cipher suite and hence this issue is not seen in older versions. 6.11 with its updated openSSL module negotiates RSA PSS but fails due to the implementation bug on Microsoft side. So far it seems like only devices with TPM 2.0 revision 1.16 has this issue. If the device supports TPM upgrade, that is one way to fix the issue. However TPM update is not an option in all cases.Work arounds are to disable RSA-PSS on windows client side or TPM update. If either these options doesn't work, TAC might be able to help disable TLS 1.2 from support shell.
Original Message:Sent: Apr 21, 2023 03:58 AMFrom: jonas.hammarbackSubject: Clients affected by CP‑49353 in ClearPass 6.11 from Windows 10
in case still have anyone is suffering this issue, I think this is the solution from CPPM side
Disable RSA-PSS Signature Suite in EAP-TLS
Set this value to TRUE to assist Windows 10 devices using a Trusted Platform Module (TPM) authenticate when certificates installed in the TPM fail with a RSA_verify_PKCS1_PSS_mgf1:last octet invalid error. This issue is reported in ClearPass 6.11.x and later deployments on some Windows 10 devices using TPM, especially TPM 1.16 and lower. This issue does not impact pre 6.11.x ClearPass versions. The default value is FALSE.
From my research, the issue is with TPM 2.0 firmware from the various hardware manufacturers. It is therefore not a Microsoft implementation issue, but a manufacturer-specific firmware issue. This is not listed in the Release Notes as a Behavior change. Many users reading the Release Notes do not comb through all the issues entries.I realize this support allows enhancing FIPS support. Is Aruba planning an option to not negotiate RSA PSS in non-FPS systems for improved compatibility? Most of the clients on our network are running Windows 10 and our testing has revealed these TLS compatibility issues. The majority of our clients are personally owned by students & staff so we have no control over firmware versions.If we wish to maintain ClearPass support past the end of the year, we are forced to move to 6.11.x. In my personal opinion, we need a more compatible solution that currently offered. We have been a ClearPass customer since the early days of Aruba's purchase of Avenda. This is the first time, in my memory, where we do not see a viable path to maintain product support. In fact, our proof of concept was before Aruba rebranded the product.To reiterate, the above statements are based on my personal opinions and experiences with this product.Thank you again for highlight this issue that i missed in the Release Notes.
Hi BruceI agree with your statement that an option in the GUI to disable PSS RSA support would be good and I have filed a feature request in the Innovation zone: https://innovate.arubanetworks.com/ideas/SEC-I-1960Please vote on the idea if you find it useful
An update for anyone running into the same issue and need a quick guide how to solve the issue for the clients.We implemented a fix by removing the PSS RSA algorithm for the customer with clients with this issue by pushing a GPO removing the keys below.The values that need to be removed are found under:Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003Remove the following values:RSAE-PSS/SHA256RSAE-PSS/SHA384RSAE-PSS/SHA512For clients that was already in a state where they could not authenticate we had to work around that by either allowing MAC authentication or in some cases manually disable the authentication on the switch port for some time to allow the client to retrieve the new settings in the GPO.
Does it also appear with PEAP + EAP-TLS Method? We get all the time timeouts and don´t know why since 6.11
HiI don't know if it's an issue in PEAP with EAP-TLS as inner method as well, but I guess so.Do you get any error message related to the timeouts?
Unfortunatelly no, Only "Timeouts" in Reauthentication
HiTimeouts are often a result of a mismatch in the client configuration in relation to the ClearPass server certificate.The client settings must allow the client to accept the Radius certificate.The issue described seems to be another issue maybe better for a separate thread, or a TAC case.
hi Jonas,this is great information was really helpful after a 6.11 upgrade went as follows :-Migrated to 6.11.2 Windows clients authenticating ok, customer happy.Next day Windows authenticating ok but a different batch of Windows clients couldn't get authenticated and in Access tracker we were getting the erroryou've seen (EAP-TLS fatal error decrypt etc.) so we (through GPO) changed the cypher suite and it worked just fine.thanks again great post.
© Copyright 2023 Hewlett Packard Enterprise Development LPAll Rights Reserved.