we're also facing the issue and yes not storing the certificate with TPM fixes the issue but we want to store certificates as secure as possible.
We're troubleshooting this quite a time for now and we will patch the SSL part of freeRADIUS to write out all possible logs we can get to know which octet is invalid and also why.
Hopefully we're able fix the issue on server site.
> Windows WiFi profile was set to auto-join (non-interactive)
Do you don't have the problem if you're using user-certificates and a interactive WiFi profile?
> Built-in security measures control access to keys in that CSP, and it cannot be used non-interactively
How have you verify it? We've played a little bit with the settings and anyhow the certificate is stored with TPM, the error occurs.
Just to reference, which certificates are you using? In your last post a SCEPman URL was visible in the logs. Have you tried other certificates which are stored with TPM?
<quote author='Users mailing list'>
2 months later, a quick update on this topic (apologies, I may have
broken the threading as I don't have a copy of the original e-mails any
more!), just so there's an online reference here for anyone encountering
the same error.
Turns out I was wrong about it being Windows and OpenSSL getting muddled
over TLS 1.2 vs. 1.3...
To recap: Windows 10 clients, corporate WiFi network using EAP-TLS to
RADIUS with machine certificate (SCEP) authentication only.
Error in Freeradius logs:
(6) eap_tls: ERROR: TLS Alert write:fatal:decrypt error
tls: TLS_accept: Error in error
(6) eap_tls: ERROR: Failed in __FUNCTION__ (SSL_read)
(6) eap_tls: ERROR: error:0407E086:rsa
routines:RSA_verify_PKCS1_PSS_mgf1:last octet invalid
(6) eap_tls: ERROR: error:1417B07B:SSL
(6) eap_tls: ERROR: System call (I/O) error (-1)
(6) eap_tls: ERROR: TLS receive handshake failed during operation
(6) eap_tls: ERROR: [eaptls process] = fail
After encountering the error on a few machines again, even with
"tls_max_version" set, I delved into the guts of Windows again, and
found the error (which isn't helpful or descriptive) was actually caused
* Some machine certificates had were stored/managed by the "Microsoft
Platform Crypto Provider" (TPM-backed)
* Built-in security measures control access to keys in that CSP, and it
cannot be used non-interactively
* Windows WiFi profile was set to auto-join (non-interactive)
* Windows couldn't get the key, so $deity knows what signature it was
* OpenSSL rightly got confused
Ensure machine certificate keys are stored in the "Microsoft Software
Key Storage Provider" (or another CSP/KSP that permits non-interactive
All is well again, and I'm close to shutting down NPS :-)
Information Security Adviser
Alan DeKok wrote:
> 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"
Good to hear.
> 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.
Weird, but OK. It's OpenSSL :(
List info/subscribe/unsubscribe? See
Sent from http://freeradius.1045715.n5.nabble.com
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
|Free forum by Nabble||Edit this page|