eap_peap: ERROR: TLS Alert read:fatal:unknown CA
Hello everyone, We've recently upgraded one of our freeradius servers to 3.0.17, the configuration remains unchanged. Now, whenever a device connects to WiFi, the authentication fails with: eap_peap: ERROR: TLS Alert read:fatal:unknown CA Downgrading freeradius to 3.0.16 fixes the issue, as well as disabling certificate checking on the client device (but that's obviously not an option). I've also tried all later versions including 3.0.20, all of them have this problem. Similarly, all versions 3.0.13 - 3.0.16 are working successfully. I was able to rule out the specific git commit which introduces this problem. #66c66729a51713c8a282b483e3cc76b43a234efa is the last working version (checked out and built from source). #595b4ddb9571772322ad2546f0faba91aa32daf1 seems to be the first "faulty" version. Any ideas how to fix this issue? I would like to attach the complete output of freeradius -X, but that contains identifying information that's hard to strip. But if you need more information, I'll see what I can do. For now, see the output of freeradius -X for the failing connection. Is this a bug? I don't think that the behavior of freeradius should change from 3.0.16 to 3.0.17, especially as the commit message for #595b4ddb9571772322ad2546f0faba91aa32daf1 only says: "TLS: Allow partial certificate chain to trusted CA". That doesn't feel like some functionality was removed, does it? Thanks in advance, L. Rose
On Nov 19, 2019, at 1:45 PM, L. Rose <lists@lrose.de> wrote:,
We've recently upgraded one of our freeradius servers to 3.0.17, the configuration remains unchanged. Now, whenever a device connects to WiFi, the authentication fails with:
eap_peap: ERROR: TLS Alert read:fatal:unknown CA
Downgrading freeradius to 3.0.16 fixes the issue, as well as disabling certificate checking on the client device (but that's obviously not an option). I've also tried all later versions including 3.0.20, all of them have this problem. Similarly, all versions 3.0.13 - 3.0.16 are working successfully.
That isn't good.
I was able to rule out the specific git commit which introduces this problem. #66c66729a51713c8a282b483e3cc76b43a234efa is the last working version (checked out and built from source). #595b4ddb9571772322ad2546f0faba91aa32daf1 seems to be the first "faulty" version.
That's just a merge commit. The actual change is in 8e54822dcaf1. Which just sets a flag in OpenSSL.
Any ideas how to fix this issue? I would like to attach the complete output of freeradius -X, but that contains identifying information that's hard to strip. But if you need more information, I'll see what I can do. For now, see the output of freeradius -X for the failing connection.
Is this a bug? I don't think that the behavior of freeradius should change from 3.0.16 to 3.0.17, especially as the commit message for #595b4ddb9571772322ad2546f0faba91aa32daf1 only says: "TLS: Allow partial certificate chain to trusted CA". That doesn't feel like some functionality was removed, does it?
It shouldn't change anything. What do your certificate chains look like? Maybe OpenSSL is getting the certificate chains wrong. Try setting "auto_chain = no" in mods-available/eap. Be aware though that this means you will need to order the certificates yourself. i.e. "certificate_file" will have to contain the entire certificate chain, in order. Alan DeKok.
Hello there, I had the similar issue today for FR 3.0.20. I set the following settings in mods-available/eap By the way my OpenSSL version is 1.1.1d tls_min_version = "1.2" tls_max_version = "1.3" I restarted and everything worked well like a charm. I hope this will work for you too. İbrahim AKŞİT Best Regards and Wishes Yours Sincerely. On Tue, Nov 19, 2019 at 11:08 PM Alan DeKok <aland@deployingradius.com> wrote:
On Nov 19, 2019, at 1:45 PM, L. Rose <lists@lrose.de> wrote:,
We've recently upgraded one of our freeradius servers to 3.0.17, the
configuration remains unchanged. Now, whenever a device connects to WiFi, the authentication fails with:
eap_peap: ERROR: TLS Alert read:fatal:unknown CA
Downgrading freeradius to 3.0.16 fixes the issue, as well as disabling
certificate checking on the client device (but that's obviously not an option). I've also tried all later versions including 3.0.20, all of them have this problem. Similarly, all versions 3.0.13 - 3.0.16 are working successfully.
That isn't good.
I was able to rule out the specific git commit which introduces this problem. #66c66729a51713c8a282b483e3cc76b43a234efa is the last working version (checked out and built from source). #595b4ddb9571772322ad2546f0faba91aa32daf1 seems to be the first "faulty" version.
That's just a merge commit. The actual change is in 8e54822dcaf1. Which just sets a flag in OpenSSL.
Any ideas how to fix this issue? I would like to attach the complete output of freeradius -X, but that contains identifying information that's hard to strip. But if you need more information, I'll see what I can do. For now, see the output of freeradius -X for the failing connection.
Is this a bug? I don't think that the behavior of freeradius should change from 3.0.16 to 3.0.17, especially as the commit message for #595b4ddb9571772322ad2546f0faba91aa32daf1 only says: "TLS: Allow partial certificate chain to trusted CA". That doesn't feel like some functionality was removed, does it?
It shouldn't change anything.
What do your certificate chains look like? Maybe OpenSSL is getting the certificate chains wrong.
Try setting "auto_chain = no" in mods-available/eap. Be aware though that this means you will need to order the certificates yourself. i.e. "certificate_file" will have to contain the entire certificate chain, in order.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 11/19/19 9:05 PM, Alan DeKok wrote:
That's just a merge commit. The actual change is in 8e54822dcaf1. Which just sets a flag in OpenSSL. It shouldn't change anything. Yes, that's what I thought as well. Despite it's only a flag in OpenSSL, it's the commit where it stops working What do your certificate chains look like? Maybe OpenSSL is getting the certificate chains wrong.
Try setting "auto_chain = no" in mods-available/eap. Be aware though that this means you will need to order the certificates yourself. i.e. "certificate_file" will have to contain the entire certificate chain, in order.
I added auto_chain = no in mods-available/eap within the tls { ... } section, but the behavior didn't change. It still only works when the client does not check the certificate. Any further ideas? The certificate chain is attached. Thanks a lot, L. Rose
On Nov 26, 2019, at 7:11 AM, L. Rose <lists@lrose.de> wrote:
On 11/19/19 9:05 PM, Alan DeKok wrote:
That's just a merge commit. The actual change is in 8e54822dcaf1. Which just sets a flag in OpenSSL. It shouldn't change anything. Yes, that's what I thought as well. Despite it's only a flag in OpenSSL, it's the commit where it stops working What do your certificate chains look like? Maybe OpenSSL is getting the certificate chains wrong.
Try setting "auto_chain = no" in mods-available/eap. Be aware though that this means you will need to order the certificates yourself. i.e. "certificate_file" will have to contain the entire certificate chain, in order.
I added auto_chain = no in mods-available/eap within the tls { ... } section, but the behavior didn't change. It still only works when the client does not check the certificate. Any further ideas? The certificate chain is attached.
Maybe set "min_tls_version = 1.2" In the end, this is a certificate / OpenSSL issue. FreeRADIUS just calls OpenSSL for the SSL magic. If there's an issue with that, it is very rarely the fault of FreeRADIUS. Alan DeKok.
First, thanks a lot for the help so far. I'm still trying to fix this issue, and it's really nice to be able to talk to some experts.
Maybe set "min_tls_version = 1.2"
I tried adding "tls_min_version = 1.2" (as I suppose that's the correct spelling of that option), but it didn't change the behavior. It still works on versions before #8e54822d..., and fails on versions after and including #8e54822d... However, I found out that adding auto_chain = no does indeed change something. It doesn't cause the newer (failing) versions to work (which is what I tested yesterday), but it also causes the older (working) versions to fail as well. Maybe our certificate chain isn't in order? What order is needed?
In the end, this is a certificate / OpenSSL issue. FreeRADIUS just calls OpenSSL for the SSL magic. If there's an issue with that, it is very rarely the fault of FreeRADIUS.
But if it's an OpenSSL-issue, how can changing the freeradius build version have an impact? Doesn't it need to be somewhat related to freeradius, if downgrading fixes the issue? And I thought that the error message "unknown CA" is issued by the client, as the client is rejecting the certificate when using newer versions of freeradius. Am I wrong? Thanks again for your time, Lukas
On Nov 27, 2019, at 7:10 AM, L. Rose <lists@lrose.de> wrote:
First, thanks a lot for the help so far. I'm still trying to fix this issue, and it's really nice to be able to talk to some experts.
Maybe set "min_tls_version = 1.2"
I tried adding "tls_min_version = 1.2" (as I suppose that's the correct spelling of that option),
Yes, that's right.
but it didn't change the behavior. It still works on versions before #8e54822d..., and fails on versions after and including #8e54822d...
However, I found out that adding auto_chain = no does indeed change something. It doesn't cause the newer (failing) versions to work (which is what I tested yesterday), but it also causes the older (working) versions to fail as well. Maybe our certificate chain isn't in order? What order is needed?
From the comments in mods-available/eap: # This file should contain the server certificate, # followed by intermediate certificates, in order. # i.e. If we have a server certificate signed by CA1, # which is signed by CA2, which is signed by a root # CA, then the "certificate_file" should contain # server.pem, followed by CA1.pem, followed by # CA2.pem.
In the end, this is a certificate / OpenSSL issue. FreeRADIUS just calls OpenSSL for the SSL magic. If there's an issue with that, it is very rarely the fault of FreeRADIUS.
But if it's an OpenSSL-issue, how can changing the freeradius build version have an impact? Doesn't it need to be somewhat related to freeradius, if downgrading fixes the issue?
The patch asks OpenSSL to do a little more work. Apparently this breaks things.
And I thought that the error message "unknown CA" is issued by the client, as the client is rejecting the certificate when using newer versions of freeradius. Am I wrong?
It could come from either end. But here it's likely coming from the client. The issue then is that the certificate chain sent by the server uses a CA which the client doesn't know. *Or* the certificate chain is missing a CA. Follow the instructions above to order the certificates properly, and it should work. For some unknown reason, OpenSSL is unable to correctly produce certificate chains itself. Spoon-feeding OpenSSL will fix that problem. Alan DeKok.
From the comments in mods-available/eap:
# This file should contain the server certificate, # followed by intermediate certificates, in order. # i.e. If we have a server certificate signed by CA1, # which is signed by CA2, which is signed by a root # CA, then the "certificate_file" should contain # server.pem, followed by CA1.pem, followed by # CA2.pem.
Thanks for the advise, I was able to fix the problem. I created a fullchain.pem containing the server certificate and all intermediate certificates, and now it works with all clients even on newer versions of freeradius. Thanks a lot! Kind regards, Lukas
participants (3)
-
Alan DeKok -
Ibrahim AKSIT -
L. Rose