Windows 10 EAP-TLS w/ smartcard

[BuzzSaw Code]

Working with a small network that has Linux, macOS, and Windows systems.

- FreeRADIUS on RHEL8 servers in FIPS mode using the most recent RPM
version provided by RedHat (3.0.20-12)

- All systems have a system certificate deployed from an internal CA
that is used for wired or wireless EAP-TLS/802.1x that works.

- Some users now have smartcards that they want to incorporate.
Smartcards are issued by external CA but both FreeRADIUS and clients
have the root CAs and intermediate CAs  installed required for them.

- Smartcards work fine on Linux and macOS systems for EAP-TLS wired or wireless

- Smartcards work on the Windows systems for web browsing/email/other
applications that require them.

- Smartcards fail weirdly on Windows 10 (22H2) when used with EAP-TLS
with this error in the EapMethods-RasTls event logs:
"Authentication failed for EAP method type 13. The error was 0x80090331."

That error code is supposedly "The client and server cannot
communicate, because they do not possess a common algorithm."

Wireshark packet captures of the EAP conversation show the client
sending its list of ciphers it supports in the Client-Hello, and then
the Server-Hello coming back using one of those ciphers. But the
Windows 10 host stops responding and simply says it could not connect
when using the smartcard.

The same host works fine when using the computer certificate and the
cipher exchange looks the same in that case.

- Old Windows builds (Windows 8.1for example) can connect to wireless
or wired using the same smartcard without issues.

- If we completely disable FIPS on the FreeRADIUS server, the Windows
10 clients can suddenly connect, despite the fact that the same
ciphers appear to be selected in the EAP ClientHello/ServerHello
handshake.

I'm posting here in hopes that someone has suggestions on how we can
debug this on the Windows side - we've run through the EventViewer
logs and done netsh tracing but it never tells us exactly what cipher
it thinks it can't match or any specific enough information to take
action on.

We would be convinced this is a certificate/trust issue if it were not
for the ability to turn off FIPS on the server to make it work.

Has anyone debugged something like this on Windows that could offer
some tips on getting more information from the Windows system on what
exactly it is seeing as a mismatch ?