I have configured FreeRADIUS with EAP-TTLS/GTC and I am using valid certificates issued by Let's Encrypt. The certificate is valid for radius.foo.it and I have cert.pem, chain.pem, fullchain.pem, and privkey.pem. I have configured the tls section of the FreeRADIUS eap module as follows: ``` private_key_file = ${certdir}/privkey.pem certificate_file = ${certdir}/fullchain.pem ca_file = ${cadir}/fullchain.pem auto_chain = no ``` When I try to connect to the access point with an older Android device, I have no issues, as it uses the system certificates. Using Linux and specifying the CA Authority as the Let's Encrypt root, I encounter no problems either. However, when using an iPad, I am prompted to accept the certificate (which is the correct one), but it claims it is untrusted despite the Let's Encrypt root being among the trusted CA. With newer versions of Android, you can choose between 3 options: do not verify, request certificate status, and require certificate status. The first two options work (by entering radius.foo.it as the domain), but for security reasons, I would like the third option to work as well. However, I get this error: ``` (13) eap: Peer sent EAP Response (code 2) ID 5 length 13 (13) eap: Continuing tunnel setup (13) [eap] = ok (13) } # authorize = ok (13) Found Auth-Type = eap (13) # Executing group from file /etc/freeradius/sites-enabled/default (13) authenticate { (13) eap: Expiring EAP session with state 0xf0bbd072f4bec5d6 (13) eap: Finished EAP session with state 0xf0bbd072f4bec5d6 (13) eap: Previous EAP request found for state 0xf0bbd072f4bec5d6, released from the list (13) eap: Peer sent packet with method EAP TTLS (21) (13) eap: Calling submodule eap_ttls to process data (13) eap_ttls: Authenticate (13) eap_ttls: (TLS) EAP Done initial handshake (13) eap_ttls: (TLS) recv TLS 1.2 Alert, fatal internal_error (13) eap_ttls: (TLS) The client is informing us that there is a failure inside the TLS protocol exchange. (13) eap_ttls: ERROR: (TLS) Alert read:fatal:internal error (13) eap_ttls: (TLS) Server : Need to read more data: error (13) eap_ttls: ERROR: (TLS) Failed reading from OpenSSL: error:0A000438:SSL routines::tlsv1 alert internal error (13) eap_ttls: (TLS) In Handshake Phase (13) eap_ttls: (TLS) Application data. (13) eap_ttls: ERROR: (TLS) Cannot continue, as the peer is misbehaving. (13) eap_ttls: ERROR: [eaptls process] = fail (13) eap: ERROR: Failed continuing EAP TTLS (21) session. EAP sub-module failed (13) eap: Sending EAP Failure (code 4) ID 5 length 4 ``` There is definitely something wrong with the configuration, but honestly, I can't figure out what. Any advice? I'm using the official freeradius docker container version 3.2.3. Thank you in advance. P.S. I am 100% sure that the certificate is valid, which can be verified using openssl verify or by creating a virtual host with HTTPS using Apache.
On Feb 23, 2024, at 6:01 AM, Lorenzo Mirabella <lorenzo.mirabella@outlook.it> wrote:
I have configured FreeRADIUS with EAP-TTLS/GTC and I am using valid certificates issued by Let's Encrypt. The certificate is valid for radius.foo.it and I have cert.pem, chain.pem, fullchain.pem, and privkey.pem. I have configured the tls section of the FreeRADIUS eap module as follows:
That should work. The caveat is that TLS algorithms change over time. So newer certs might not be accepted by older devices.
When I try to connect to the access point with an older Android device, I have no issues, as it uses the system certificates. Using Linux and specifying the CA Authority as the Let's Encrypt root, I encounter no problems either. However, when using an iPad, I am prompted to accept the certificate (which is the correct one), but it claims it is untrusted despite the Let's Encrypt root being among the trusted CA. With newer versions of Android, you can choose between 3 options: do not verify, request certificate status, and require certificate status. The first two options work (by entering radius.foo.it as the domain), but for security reasons, I would like the third option to work as well. However, I get this error: ... (13) eap_ttls: (TLS) recv TLS 1.2 Alert, fatal internal_error (13) eap_ttls: (TLS) The client is informing us that there is a failure inside the TLS protocol exchange.
The client says "no". Why? "no". What went wrong? "Too bad, not telling you". How friendly.
There is definitely something wrong with the configuration, but honestly, I can't figure out what. Any advice?
There's nothing wrong with the configuration. One client doesn't like what the server is doing. But all other clients are fine. So the problem isn't really FreeRADIUS.
I'm using the official freeradius docker container version 3.2.3.
Thank you in advance.
P.S. I am 100% sure that the certificate is valid, which can be verified using openssl verify or by creating a virtual host with HTTPS using Apache.
"TLS works" involves a whole lot more than a binary choice of "yes" or "no". There's TLS 1.0, 1.1, 1.2, and 1.3. Within each TLS version, there are dozens of choices for encryption methods, and more choices for digest methods. If by some miracle both sides agree, then it works. If both sides don't agree on the various versions, methods, etc., then things don't work. And you get helpful error messages like "failed". In most cases, up-to-date devices will "just work". So if a device doesn't work, then either it's running old software, or it's not configured correctly. Perhaps try configuring FreeRADIUS to limit the TLS versions it's using. The server will do TLS 1.3, but older clients won't do TLS 1.3 correctly. Maybe set the maximum TLS version to 1.2, or even 1.1. Then see if it works. There are too many variants of devices for us to keep up. Apple && Google's budget for coffee and snacks is multiple times the yearly budget of all FreeRADIUS developers put together. We just can't keep up. We can only give vague advice about what usually works, and then hope for the best. Alan DeKok.
On 23/02/2024 11:01, Lorenzo Mirabella wrote:
ca_file = ${cadir}/fullchain.pem
A separate point, do NOT add this line. It is the root CA that FreeRADIUS will use to verify client certificates. i.e. if a client comes along and tries to authenticate with EAP-TLS and presents a certificate from that root, they will be accepted. Which means in your situation, anyone with a LetsEncrypt will be able to authenticate. This is certainly not what you want. For EAP-TLS, set it to a private root CA. For any other EAP type, leave it unset. -- Matthew
participants (3)
-
Alan DeKok -
Lorenzo Mirabella -
Matthew Newton