On 2020-06-11 13:51, Peter Bance via Freeradius-Users wrote:
On 2020-06-11 12:48, Alan DeKok wrote:
On Jun 11, 2020, at 4:31 AM, Peter Bance via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I'm afraid I've been all around the Windows and certificate side, and I've circled back to FreeRADIUS :( I probably should have included the full session log before (sadly I didn't think to save a successful entry from iOS to compare it to, I'll try and get one when I next can). I've pasted below (I don't think I need to "redact" anything here other than the SSID and OUs, which identified the client).
One thing strikes me, and the reason I'm being a nuisance here again (!) - the signature validation is failing "RSA_verify_PKCS1_PSS_mgf1", but both the client and CA certificates are signed with "sha256WithRSAEncryption", and the session is TLS 1.2. However, the very first client request asks for TLS 1.3 (subsequently downgraded to 1.2).
Well, if the TLS stuff is wrong, blame OpenSSL. We rely on OpenSSL for that.
A final update on this, in case anyone here's interested (or to "wrap up" for anyone stumbling across this thread online) - I fixed it, and Windows clients are now happily joining WiFi. It's a beautiful thing to behold :-) In the end, I had to force OpenSSL on FreeRADIUS to stop offering TLS1.3 ciphers using the mods/eap config: tls_max_version = "1.2" It seems there may be a bug in OpenSSL 1.1.1 such that even though the negotiation resulted in a TLS 1.2 session, the weird back-port of TLS 1.3 ciphers into TLS 1.2 confused things (a lot), and it tried checking for TLS 1.3 style signatures inappropriately. --- Peter Bance Information Security Adviser