EAP-TLS Signature Check Failure

Alan DeKok aland at deployingradius.com
Thu Jun 11 13:48:23 CEST 2020

On Jun 11, 2020, at 4:31 AM, Peter Bance via Freeradius-Users <freeradius-users at 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.

> Could FreeRADIUS be "remembering" the initial 1.3, and thus trying an invalid signature validation on the certificate(s)?

  No.  The TLS negotiation is handled by OpenSSL, and FreeRADIUS knows very little about it.

  Further, EAP-TLS for TLS 1.3 isn't even standardized yet.  I've been in touch with the Microsoft engineer who's implementing it.  We should be doing Windows / FreeRADIUS interoperation in the next month or so.  So when it is released, Windows will work.

> I've tried going through the source code, but I confess my C and TLS skills aren't up to it :-(

  I don't touch OpenSSL.  That code is a nightmare.

  Maybe it's an issue with OpenSSL?



  Are you using RedHat?  Maybe you're running into the issue of RedHat replacing OpenSSL with NSS.  It's not the same, and it doesn't work.  You might have to drop the RH packages, and move to ours at http://packages.networkradius.com

  Alan DeKok.

More information about the Freeradius-Users mailing list