TLS with intermediate certificate issue
Hello, We're running into an issue where EAP-TLS authentication is failing due to the 'unable to get issuer certificate' error. This is only the case when freeRADIUS certificate was issued by the intermediate CA server (signed by the Root CA) and the client certificate was also issued by the intermediate CA server but Root CA installed on it. Note that Trusted CA (ca_file ==> external_ca.pem) in freeradius does NOT include the the Root CA and it only has the CA cert that's issuing the certificate (intermediate certificate). Snippet of eap configuration is as below (no CRL involved). tls-config tls-common { certdir = ${confdir}/certs cadir = ${confdir}/certs private_key_password = password private_key_file = ${certdir}/external_server.pem certificate_file = ${certdir}/external_server.pem ca_file = ${cadir}/external_ca.pem dh_file = ${certdir}/dh 2022-07-25 09:02:25,557: Debug: (259) eap_tls: (TLS) EAP Continuing ... 2022-07-25 09:02:25,557: Debug: (259) eap_tls: (TLS) EAP Peer sent flags --- 2022-07-25 09:02:25,557: Debug: (259) eap_tls: (TLS) EAP Got final fragment (313 bytes) 2022-07-25 09:02:25,557: Debug: (259) eap_tls: (TLS) EAP Verification says ok 2022-07-25 09:02:25,557: Debug: (259) eap_tls: (TLS) EAP Done initial handshake 2022-07-25 09:02:25,557: Debug: (259) eap_tls: (TLS) recv TLS 1.2 Handshake, Certificate 2022-07-25 09:02:25,557: Debug: (259) eap_tls: Generating SHA-1 Fingerprint for certificate 2022-07-25 09:02:25,557: Debug: (259) eap_tls: ETS-TLS-Cert-Fingerprint := "1C0D90361737BB7B7B8EAE62FDF7E6A680042DF9" 2022-07-25 09:02:25,557: Debug: (259) eap_tls: (TLS) Creating attributes from server certificate 2022-07-25 09:02:25,557: Debug: (259) eap_tls: TLS-Cert-Serial := "3b0000000a0d548d27e286f0ca00000000000a" 2022-07-25 09:02:25,557: Debug: (259) eap_tls: TLS-Cert-Expiration := "240722144713Z" 2022-07-25 09:02:25,557: Debug: (259) eap_tls: TLS-Cert-Valid-Since := "220722143713Z" 2022-07-25 09:02:25,557: Debug: (259) eap_tls: TLS-Cert-Subject := "/DC=com/DC=extrxiq-salem/DC=extrxiq-salemC/CN=extrxiq-salemC-WIN2012-752-CA" 2022-07-25 09:02:25,557: Debug: (259) eap_tls: TLS-Cert-Issuer := "/DC=com/DC=extrxiq-salem/CN=extrxiq-salem-XIQ-SALEM-WIN12-CA" 2022-07-25 09:02:25,558: Debug: (259) eap_tls: TLS-Cert-Common-Name := "extrxiq-salemC-WIN2012-752-CA" 2022-07-25 09:02:25,558: Debug: (259) eap_tls: ETS-TLS-Verify-Error-Code := 2 2022-07-25 09:02:25,558: ERROR: (259) eap_tls: (TLS) OpenSSL says error 2 : unable to get issuer certificate 2022-07-25 09:02:25,558: Debug: (259) eap_tls: (TLS) send TLS 1.2 Alert, fatal unknown_ca 2022-07-25 09:02:25,558: ERROR: (259) eap_tls: (TLS) Alert write:fatal:unknown CA 2022-07-25 09:02:25,558: ERROR: (259) eap_tls: (TLS) Server : Error in error 2022-07-25 09:02:25,558: ERROR: (259) eap_tls: (TLS) Failed reading from OpenSSL: s3_srvr.c[3344]:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed 2022-07-25 09:02:25,558: ERROR: (259) eap_tls: (TLS) System call (I/O) error (-1) 2022-07-25 09:02:25,558: ERROR: (259) eap_tls: (TLS) EAP Receive handshake failed during operation 2022-07-25 09:02:25,558: ERROR: (259) eap_tls: [eaptls process] = fail 2022-07-25 09:02:25,558: ERROR: (259) eap: Failed continuing EAP TLS (13) session. EAP sub-module failed The above example shows 'TLS-Cert-Issuer' is the root CA server which signed the intermediate certificate. A client was authenticating fine on freeRADIUS server running 3.0.21 but after we upgraded the freeRADIUS to 3.0.25, we're starting to see this issue (see above the debug). No configuration change in eap file between versions. If we install the 'root' certificate to 'ca_file' in 3.0.25 (no needed in 3.0.21 as it only required intermediate cert), then the client authentication started working. Is this known issue OR expected new behavior? If so, what would be the reason why it worked in 3.0.21 not in 3.0.25? Thanks for the help.
On Jul 25, 2022, at 10:21 AM, Young Yoon <yyoon99@gmail.com> wrote:
We're running into an issue where EAP-TLS authentication is failing due to the 'unable to get issuer certificate' error. This is only the case when freeRADIUS certificate was issued by the intermediate CA server (signed by the Root CA) and the client certificate was also issued by the intermediate CA server but Root CA installed on it. Note that Trusted CA (ca_file ==> external_ca.pem) in freeradius does NOT include the the Root CA and it only has the CA cert that's issuing the certificate (intermediate certificate).
Snippet of eap configuration is as below (no CRL involved).
http://wiki.freeradius.org/list-help We don't need to see the configuration. All of the documentation says this. Including the email you get when you join the list.
2022-07-25 09:02:25,557: Debug: (259) eap_tls: (TLS) EAP Continuing ...
We don't need to see "radiusd -Xxxxxxx" or whatever. Just "radiusd -X". Again, all of the documentation says to do this. The documentation is there for a reason. If you follow it, you will not only solve problems more quickly, it will be easier for us to help you solve problems.
2022-07-25 09:02:25,558: ERROR: (259) eap_tls: (TLS) OpenSSL says error 2 : unable to get issuer certificate
That's pretty clear.
2022-07-25 09:02:25,558: Debug: (259) eap_tls: (TLS) send TLS 1.2 Alert, fatal unknown_ca
2022-07-25 09:02:25,558: ERROR: (259) eap_tls: (TLS) Alert write:fatal:unknown CA
That's also clear. If you use 3.2.0, the error messages will be even better.
The above example shows 'TLS-Cert-Issuer' is the root CA server which signed the intermediate certificate. A client was authenticating fine on freeRADIUS server running 3.0.21 but after we upgraded the freeRADIUS to 3.0.25, we're starting to see this issue (see above the debug). No configuration change in eap file between versions. If we install the 'root' certificate to 'ca_file' in 3.0.25 (no needed in 3.0.21 as it only required intermediate cert), then the client authentication started working.
This is likely due to an OpenSSL change. But FreeRADIUS needs the CA certificate configured. If you don't have the CA configured, then anything TLS just won't work.
Is this known issue OR expected new behavior? If so, what would be the reason why it worked in 3.0.21 not in 3.0.25?
If it's not due to an OpenSSL version change (and it often is), then the issue is somewhere in the change list from 3.0.21 to 3.0.25. The source is available... Alan DeKok.
Thanks. I was able to get the log as instructed (but message being held it's too long). I can confirm that there's no OpenSSL version change (1.1.1) in our product and the only change is the freeRadius 3.0.21 to 3.0.25. Looks like the root CA (microsoft private CA) is not being trusted by default (as it was in 3.0.21) if using the intermediate certificate for TLS auth. The simple workaround is just install the root CA as ca trust store in freeRadius, but just curious if this behavior is going forward in the future or not. Thanks for your help. On Mon, Jul 25, 2022 at 10:38 AM Alan DeKok <aland@deployingradius.com> wrote:
On Jul 25, 2022, at 10:21 AM, Young Yoon <yyoon99@gmail.com> wrote:
We're running into an issue where EAP-TLS authentication is failing due to the 'unable to get issuer certificate' error. This is only the case when freeRADIUS certificate was issued by the intermediate CA server (signed by the Root CA) and the client certificate was also issued by the intermediate CA server but Root CA installed on it. Note that Trusted CA (ca_file ==> external_ca.pem) in freeradius does NOT include the the Root CA and it only has the CA cert that's issuing the certificate (intermediate certificate).
Snippet of eap configuration is as below (no CRL involved).
http://wiki.freeradius.org/list-help
We don't need to see the configuration. All of the documentation says this. Including the email you get when you join the list.
2022-07-25 09:02:25,557: Debug: (259) eap_tls: (TLS) EAP Continuing ...
We don't need to see "radiusd -Xxxxxxx" or whatever. Just "radiusd -X". Again, all of the documentation says to do this.
The documentation is there for a reason. If you follow it, you will not only solve problems more quickly, it will be easier for us to help you solve problems.
2022-07-25 09:02:25,558: ERROR: (259) eap_tls: (TLS) OpenSSL says error 2 : unable to get issuer certificate
That's pretty clear.
2022-07-25 09:02:25,558: Debug: (259) eap_tls: (TLS) send TLS 1.2 Alert, fatal unknown_ca
2022-07-25 09:02:25,558: ERROR: (259) eap_tls: (TLS) Alert write:fatal:unknown CA
That's also clear.
If you use 3.2.0, the error messages will be even better.
The above example shows 'TLS-Cert-Issuer' is the root CA server which signed the intermediate certificate. A client was authenticating fine on freeRADIUS server running 3.0.21 but after we upgraded the freeRADIUS to 3.0.25, we're starting to see this issue (see above the debug). No configuration change in eap file between versions. If we install the 'root' certificate to 'ca_file' in 3.0.25 (no needed in 3.0.21 as it only required intermediate cert), then the client authentication started working.
This is likely due to an OpenSSL change.
But FreeRADIUS needs the CA certificate configured. If you don't have the CA configured, then anything TLS just won't work.
Is this known issue OR expected new behavior? If so, what would be the reason why it worked in 3.0.21 not in 3.0.25?
If it's not due to an OpenSSL version change (and it often is), then the issue is somewhere in the change list from 3.0.21 to 3.0.25. The source is available...
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 26, 2022, at 10:21 AM, Young Yoon <yyoon99@gmail.com> wrote:
Thanks. I was able to get the log as instructed (but message being held it's too long).
If you convert it to HTML, yes. Just post text.
I can confirm that there's no OpenSSL version change (1.1.1) in our product and the only change is the freeRadius 3.0.21 to 3.0.25.
Looks like the root CA (microsoft private CA) is not being trusted by default (as it was in 3.0.21)
No. FreeRADIUS doesn't come with any private CAs by default. No CAs are trusted by default. You have to configure the CAs in the raddb/certs directory.
if using the intermediate certificate for TLS auth. The simple workaround is just install the root CA as ca trust store in freeRadius, but just curious if this behavior is going forward in the future or not.
You've always had to configure the root CA in FreeRADIUS. Alan DeKok.
participants (2)
-
Alan DeKok -
Young Yoon