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