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 ?