Hi everyone I just wanted let you know that we have found an error in combination with TPM-saved RSA certificates and Client Authentication on TLS1.2 with newer Windows 10 Clients (probably all after 1909). It seems that a lot of 2.0 TPMs have a problem with RSA PSS. I wanted to share this problem because we have spent a lot of time to identify the issue. So I hope that other admins will find this post before they spend a lot of time in troubleshooting. The issue happens during the TLS handshake. The TPM just doesn't signs the certificate verify step as shown on this print screen: By disabling RSA PSS on the client, the client uses another cipher to sign the packet and then it works. You can disable RSA PSS by following those steps: Backup this key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003 Under Functions remove the following signature suites from the list: RSAE-PSS/SHA256 RSAE-PSS/SHA384 RSAE-PSS/SHA512 Reboot After the reboot, the client uses now RSA PKCS1 and the signature step runs successful: The issue was initially identified on a EAP-TLS authentication for an IPSec tunnel. But the issue happens also on client certificate authentication on https websites as both use TLS for the handshake. Keep in mind that this is only a workaround and should not be used as a final solution. We are actually still working with Microsoft on a solution. It's still not 100% clear if it's the TPM that is making the issue or if it is the OS. I will keep you updated...

Was there ever any proper solution to this issue? We are encountering this with our older TPM 1.2 devices with always on VPN tunnels using PEAP-TLS, and wondered if we could have Windows instead store certs/keys for the VPN certificates in the software crypto provider rather than TPM? Cheers James

THANK YOU for this. Mystery handshake error with EAP/TLS Wi-Fi authentication to Cisco ISE on Surface Pro 4 solved instantly. (after hours of head scratching in the lab)

Thanks for the information! This caused connection problems to the AlwaysOn VPN service in Azure on our user computers that were recently updated to the Win 10 23H2 version. Manually removing those three ciphers did fix the issue. Another solution is to revert back to 22H2 update. The error message in Event viewer was: The user xxxxx dialed a connection named xxxxx which has failed. The error code returned on failure is -1878457596.

Windows 10 TPM 2.0 Client Authentication in TLS 1.2 with RSA PSS making trouble

S1ngl3t0n 21

Hi everyone

I just wanted let you know that we have found an error in combination with TPM-saved RSA certificates and Client Authentication on TLS1.2 with newer Windows 10 Clients (probably all after 1909).
It seems that a lot of 2.0 TPMs have a problem with RSA PSS.

I wanted to share this problem because we have spent a lot of time to identify the issue. So I hope that other admins will find this post before they spend a lot of time in troubleshooting.

The issue happens during the TLS handshake. The TPM just doesn't signs the certificate verify step as shown on this print screen:

By disabling RSA PSS on the client, the client uses another cipher to sign the packet and then it works.
You can disable RSA PSS by following those steps:

Backup this key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003
Under Functions remove the following signature suites from the list:
RSAE-PSS/SHA256
RSAE-PSS/SHA384
RSAE-PSS/SHA512
Reboot

After the reboot, the client uses now RSA PKCS1 and the signature step runs successful:

The issue was initially identified on a EAP-TLS authentication for an IPSec tunnel. But the issue happens also on client certificate authentication on https websites as both use TLS for the handshake.

Keep in mind that this is only a workaround and should not be used as a final solution. We are actually still working with Microsoft on a solution.
It's still not 100% clear if it's the TPM that is making the issue or if it is the OS.

I will keep you updated...

Morten Rask Christensen 1 Reputation point

2022-10-05T12:40:21.863+00:00

We are also facing the same issue. Did you ever resolve it with Microsoft?
Kyle Radon 1 Reputation point

2022-10-13T16:21:45.71+00:00

Bump, same here
Adam Whiting 6 Reputation points

2022-12-05T21:35:40.297+00:00

Any update on this?
Hrvoje Kusulja 136 Reputation points MVP

2023-07-25T10:43:29.4666667+00:00

Thank you, I also confirm have the same issue, after reinstalling using latest USB from Microsoft, on Windows 10.0.22621

I also confirm that removing these 3 keys resolved the issue.

Can you confirm what is this exactly? will this be fixed in future version? should we revert those registry keys back at some point etc?

thank you so much, but this is the only solution on the internet
Emma Smith 10 Reputation points

2024-01-05T11:04:35.8666667+00:00

Thanks, I had the same issue with Win11 on an older HP laptop with tpm2.0, pulling out my hair for 3 days while trying to configure TLS/EAP, removing the 3 suites from the registry value worked for me.
AndreaMartinezGarcia 0 Reputation points

2024-02-07T12:50:42.1166667+00:00

Issue is impacting specific HW models with TPM subversion 1.16 (2.0, 0, 1.16): https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-15361
Possible WA is to either update TPM or disable RSA PSS.

Lenovo:
https://support.lenovo.com/gb/en/product_security/len-15552
DELL:
https://www.dell.com/support/kbdoc/es-es/000144419/infineon-trusted-platform-module-tpm-vulnerability-cve-2017-15361-impact-status-on-dell-products?lang=en
Weigand, Robert 0 Reputation points

2024-05-01T06:59:35.21+00:00

When RSA PSS is deactivated on the client, a lot of TLS 1.3 enabled websites and services were not reachable from and on our Win11 clients. IIS Express, LRS Personal Print Manager, Whiteboard, Invoke-WebRequest to a lot of websites, like https://www.microsoft.com did not work.

We resorted to temporary disabling client and server-side TLS 1.3 on the clients (setting under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server and Client, Enabled=0).

We're in a process of setting the defaults back for most of our client computers, since only the oldest models (Lenovo Tx80 and M920) are still on TPM 2.0 Rev 1.16. All the other TPM 2.0 1.38 and higher models seem to work fine with the default configuration.

8 answers

James Edmonds 821 Reputation points

2022-08-23T14:50:43.72+00:00

Was there ever any proper solution to this issue?

We are encountering this with our older TPM 1.2 devices with always on VPN tunnels using PEAP-TLS, and wondered if we could have Windows instead store certs/keys for the VPN certificates in the software crypto provider rather than TPM?

Cheers
James
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
danwheeler 10 Reputation points

2023-01-18T23:17:03.91+00:00

THANK YOU for this. Mystery handshake error with EAP/TLS Wi-Fi authentication to Cisco ISE on Surface Pro 4 solved instantly. (after hours of head scratching in the lab)
Please sign in to rate this answer.
Peixoto, Victor 1 Reputation point

2024-01-03T11:18:53.64+00:00

Thanks this also resolved a mystery issue with AOVPN and Win 2022 NPS servers, auth worked fine with 2019 NPS but kept failing with 2022 NPS. Removed registry keys et voila, connected!

Alex Ledger 0 Reputation points

2024-05-14T22:08:45.3766667+00:00

Although removing 3 cipher suites from the registry resolves the issue. We found it can the cause other issues with TLS authentication. Was there any other suggestion to resolve this properly.?

Gino 6 Reputation points

2024-05-15T12:52:49.83+00:00

The only solution is to upgrade the TPM to v2.0 subversion 1.38
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Heinonen, Ari Seppo 0 Reputation points

2024-07-18T10:01:25.8533333+00:00

Thanks for the information! This caused connection problems to the AlwaysOn VPN service in Azure on our user computers that were recently updated to the Win 10 23H2 version. Manually removing those three ciphers did fix the issue. Another solution is to revert back to 22H2 update.

The error message in Event viewer was:
The user xxxxx dialed a connection named xxxxx which has failed. The error code returned on failure is -1878457596.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Windows 10 TPM 2.0 Client Authentication in TLS 1.2 with RSA PSS making trouble

8 answers

Your answer