EAP-TLS Signature Check Failure

Peter Bance peter at peterbance.co.uk
Fri Jun 12 21:34:34 CEST 2020

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 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.

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

More information about the Freeradius-Users mailing list