ISE 2.7, P2 - Windows 10 (Version 1909) cannot connect to Wireless 802.1X via TLS 1.2

[Jozef Cmorej]

Dear community,

my customer is experiencing a problem with Windows 10 after the migration from ACS to ISE 2.7, patch 2.

Windows 10 Clients (Version 1909) are using a built-in Windows Supplicant to get authentication via 802.1x to the wired and wireless network. The authentication method is PEAP-MSCHAPv2 and they use TLS 1.2 to secure the communication between the supplicant and the Radius server.

The wired 802.1x works properly without any issues.

But they are struggling to get authenticated using TLS 1.2 to the WPA-2 Enterprise network that's using certificates for server-side. The TLS handshake is completed, PEAP full handshake finished successfully. Once the TLS Tunnel is established and the client should get authenticated with the user credentials, the authentication process is interrupted from the client-side and the Radius server sends access-reject.

The PEAP authentication fails due to "12511 Unexpectedly received TLS alert message; treating as a rejection by the client"

When I conduct a test with the Windows 10 laptop using TLS 1.0, it works fine and the user gets authenticated successfully.

I have done some research on this topic and found out there is a bug - After you apply the Windows 10 November update to a device, you cannot connect to a WPA-2 Enterprise network that's using certificates for server-side or mutual authentication (EAP TLS, PEAP, TTLS).

https://support.microsoft.com/en-us/help/3121002/windows-10-devices-can-t-connect-to-an-802-1x-environment

Unfortunately, I have not found any Cisco bug ID which refers to this behavior.

Is there anybody else who experiences the same issue with Windows 10 in the combination of WPA2-Ent and TLS1.2?

Regards
Jozef

[Greg Gibbs · Accepted solution]

I've had customers using PEAP with TLS 1.2 with no problems. The MS article you referenced refers to the November update back in 2014, so I suspect this is a red herring. Also, based on the release notes for ISE 2.0 (patch 1), I suspect the bug referenced by MS is CSCuw88770. The  symptoms also state "logs show that the authentication is successful" so I think you're seeing something different.

You might want to confirm you're not using a wildcard in the CN of the ISE EAP cert as per CSCuh22029 (also an old bug, but still relevant). Windows does not like wildcards in the CN, so you need to use the FQDN for the CN attribute with a wildcard in the SAN field.

You could also try disabling TLS 1.2 on the client to confirm if the problem still exists, do a google search for the error message to find other possible issues, or engage TAC to help investigate further.

[Jozef Cmorej]

Hi Greg,

thanks for your comment.

We do not use wildcard certificates. As mentioned above, the same laptop gets authenticated using PEAP-MSCHAVPv2 with TLS 1.2 to the wired network.

I will try to disable TLS 1.2 to see if it helps.