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