EAP-TLS unable to get local issuer certificate
Hello, I am trying to setup EAP-TLS and I am getting radius server error "eap_tls: (TLS) OpenSSL says error 20 : unable to get local issuer certificate", "send TLS 1.2 Alert, fatal unknown_ca" Test client is wpa_supplicant 2.1 built on Ubuntu Linux 22.04.2. All tests are done locally on FreeRadius server 3.2.3 (Ubuntu Linux 22.04.2) When I test "client.crt" with "openssl verify ./client.crt" I get "OK". Specifying -CAFile OpenSSL parameter with chained CA cert also produces "OK". All CA certificates (there is also an intermediate certificate) are in /etc/freeradius/certs, /etc/freeradius/certs_eaptls and also /usr/lib/ssl/cert. One certificate per file. FreeRadius's EAP-TLS stanza is cadir = ${certdir}/certs_eaptls private_key_file = ${certdir}/rad.key certificate_file = ${certdir}/rad.crt auto_chain = no Server and client certificates are signed by different commercial CA. All certificates have intermediate CA. eapol_test config file for EAP-TLS is network={ key_mgmt=WPA-EAP eap=TLS identity="blabla@domain.tld" ca_cert="/etc/ssl/certs/chain.crt" client_cert="client.crt" private_key="client.key" private_key_passwd="blabla" } AppArmor disabled. Permissions for all certs are r--r--r-- (at least). OpenSSL rehash done. I have no idea what could be wrong.
On Jun 6, 2023, at 1:54 PM, MH <h33927318@gmail.com> wrote:
I am trying to setup EAP-TLS and I am getting radius server error "eap_tls: (TLS) OpenSSL says error 20 : unable to get local issuer certificate", "send TLS 1.2 Alert, fatal unknown_ca"
You haven't configured the supplicant properly. It doesn't know anything about the CA which signed the server cert. Add the CA to the client, and the message will go away. i.e. You cannot read just *part* of the error message and think that is the *whole* problem. The rest of the error message say "fatal unknown CA". That is the root cause of the problem. Alan DeKok.
But there's already ca_cert in wpa_supplicant configuration. st 7. 6. 2023 o 9:10 Alan DeKok <aland@deployingradius.com> napísal(a):
On Jun 6, 2023, at 1:54 PM, MH <h33927318@gmail.com> wrote:
I am trying to setup EAP-TLS and I am getting radius server error "eap_tls: (TLS) OpenSSL says error 20 : unable to get local issuer certificate", "send TLS 1.2 Alert, fatal unknown_ca"
You haven't configured the supplicant properly. It doesn't know anything about the CA which signed the server cert.
Add the CA to the client, and the message will go away.
i.e. You cannot read just *part* of the error message and think that is the *whole* problem. The rest of the error message say "fatal unknown CA". That is the root cause of the problem.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 7, 2023, at 9:28 AM, MH <h33927318@gmail.com> wrote:
But there's already ca_cert in wpa_supplicant configuration.
So there's nothing wrong with the configuration, and it works? Or, maybe there's something wrong with the configuration. Because it doesn't work. The error is "fatal: unknown CA". The only solution is to make sure that the CA is known. Maybe the problem is that the client certificate is issued by a CA that the server doesn't know. It's difficulty to tell, because you've "helpfully" removed nearly all of the debug output. The documentation for FreeRADIUS says to post all of the debug output. For precisely this reason. Alan DeKok.
As I wrote in my first post, "openssl verify" command outputs that client certificate is trusted. I think that without specifying "-CAFile" in "openssl verify" it looks for trusted CAs in default locations. So it works with or without -CAFile (i.e default OS system CA store and custom CA store). I expect FreeRadius does the same since it uses OpenSSL. I did run strace on "openssl verify" and I saw very clearly what files are examined for trusted CAs (it extracts IssuerName from client cert, hash it and then search for filename with that hash in trusted CA stores). I tried that same approach with "strace freeradius -fxxx" + "eapol_test ..." and did not find any similar output (just accessing server certificate and key but not any other *.PEM). Regarding the debug output: that's it. All relevant attributes from client certificate are shown and then bump "Warning: Certificate chain - 1 cert(s) untrusted", "Warning: (TLS) untrusted certificate with depth 0". st 7. 6. 2023 o 9:34 Alan DeKok <aland@deployingradius.com> napísal(a):
On Jun 7, 2023, at 9:28 AM, MH <h33927318@gmail.com> wrote:
But there's already ca_cert in wpa_supplicant configuration.
So there's nothing wrong with the configuration, and it works?
Or, maybe there's something wrong with the configuration. Because it doesn't work.
The error is "fatal: unknown CA". The only solution is to make sure that the CA is known.
Maybe the problem is that the client certificate is issued by a CA that the server doesn't know. It's difficulty to tell, because you've "helpfully" removed nearly all of the debug output. The documentation for FreeRADIUS says to post all of the debug output. For precisely this reason.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 08.06.23 07:37, MH wrote:
As I wrote in my first post, "openssl verify" command outputs that client certificate is trusted. I think that without specifying "-CAFile" in "openssl verify" it looks for trusted CAs in default locations. So it works with or without -CAFile (i.e default OS system CA store and custom CA store).
You forgot -CApath. That's still on the default, thus you are always using the system path. The name of the option is also CAfile, not CAFile. It's so much easier to really know what you are doing if you post the exact command and the exact output. Because otherwise it's always a guess if you really do what you claim to do...
I expect FreeRadius does the same since it uses OpenSSL.
That's an odd expectation. You have configured
cadir = ${certdir}/certs_eaptls private_key_file = ${certdir}/rad.key certificate_file = ${certdir}/rad.crt auto_chain = no
Assuming that's really the complete relevant configuration (and you do not have ca_file nor ca_path configured) then you don't verify certificates against a file but a path. Thus $ openssl verify -no_CAfile -noCAstore -CApath .../certs_eaptls client.crt should be the command to test. Testing against a file but using a path is kind of futile.
All CA certificates (there is also an intermediate certificate) are in /etc/freeradius/certs, /etc/freeradius/certs_eaptls and also /usr/lib/ssl/cert.
That doesn't really help either. If you put them in various dirs, some you have configured and some are system default paths, and then test with openssl verify. And without knowing what's exactly in /etc/freeradius/certs_eaptls or etc/freeradius/certs it's next to impossible to say anything. As it doesn't seem to work you seem to have either the wrong certificates or the wrong hashes or missing hashes or... It's also extremely difficult to understand if you don't post what the content of the crt files is exactly. Does rad.crt contain only the server certificate or the server certificate followed by the issuing chain excluding the root ca? Same here:
network={ key_mgmt=WPA-EAP eap=TLS identity="blabla at domain.tld" ca_cert="/etc/ssl/certs/chain.crt" client_cert="client.crt" private_key="client.key" private_key_passwd="blabla" }
Guessing from the name chain.crt, it's a chain (containes intermediate cas) and not a collection of root CAs. That is also a flawed approach and no useful test because generally you only pin root CAs on clients because that's all they really know. The TLS server delivers the chain exluding the root. The TLS client know the (preinstalled) root CAs and can verify the server chain.
I did run strace on "openssl verify" and I saw very clearly what files are examined for trusted CAs (it extracts IssuerName from client cert, hash it and then search for filename with that hash in trusted CA stores).
Again without posting the exact output, assuming here that "trusted CA stores" is /usr/lib/ssl/certs, that's to be expected because openssl verify is using the default path.
I tried that same approach with "strace freeradius -fxxx" + "eapol_test ..." and did not find any similar output (just accessing server certificate and key but not any other *.PEM).
freereadius is not using probably not the default path, thus it's a completely different outcome. But if you are using strace you should see what it is really using and accessing.
Regarding the debug output: that's it. All relevant attributes from client certificate are shown and then bump "Warning: Certificate chain - 1 cert(s) untrusted", "Warning: (TLS) untrusted certificate with depth 0".
And if you are using strace you should also see what paths freereadius is trying to verify the certificate. So unless you really post the full outputs and configs and show the full content of that directory and what those certificates really contain, that's kind of all someone can say from the outside. You claim you did everything right with now way for us to verify. Thus use the debug output and the strace and find out what's really happening. You can see from the strace what files it tries to open... -Gerald
Well, I am not very familiar with strace but I was able to use it in a way where I got this output "openat(AT_FDCWD, "/etc/freeradius/certs/b6296c9d.0", O_RDONLY) = 4". FreeRadius config is "ca_path = ${certdir}" and certdir is "/etc/freeradius/certs". File "b6296c9d.0" contains CA of client certificate. I don't know what return value 4 means. I tried "sudo -u freerad cat "/etc/freeradius/certs/b6296c9d.0" and file is readable. There are no other relevant openat() in strace. FreeRadius debug log says that certificate is untrusted. I don't know what are conditions which result in this decision. As I wrote earlier, I did not find any other openat(), so I think there were no other CA checks in chain (b6296c9d.0 contains intermediate CA). openssl verify -CAfile /etc/freeradius/certs/b6296c9d.0 /root/eapol/client.crt /root/eapol/client.crt: OK št 8. 6. 2023 o 8:28 Gerald Vogt <vogt@spamcop.net> napísal(a):
On 08.06.23 07:37, MH wrote:
As I wrote in my first post, "openssl verify" command outputs that client certificate is trusted. I think that without specifying "-CAFile" in "openssl verify" it looks for trusted CAs in default locations. So it works with or without -CAFile (i.e default OS system CA store and custom CA store).
You forgot -CApath. That's still on the default, thus you are always using the system path.
The name of the option is also CAfile, not CAFile. It's so much easier to really know what you are doing if you post the exact command and the exact output. Because otherwise it's always a guess if you really do what you claim to do...
I expect FreeRadius does the same since it uses OpenSSL.
That's an odd expectation. You have configured
cadir = ${certdir}/certs_eaptls private_key_file = ${certdir}/rad.key certificate_file = ${certdir}/rad.crt auto_chain = no
Assuming that's really the complete relevant configuration (and you do not have ca_file nor ca_path configured) then you don't verify certificates against a file but a path. Thus
$ openssl verify -no_CAfile -noCAstore -CApath .../certs_eaptls client.crt
should be the command to test. Testing against a file but using a path is kind of futile.
All CA certificates (there is also an intermediate certificate) are in /etc/freeradius/certs, /etc/freeradius/certs_eaptls and also /usr/lib/ssl/cert.
That doesn't really help either. If you put them in various dirs, some you have configured and some are system default paths, and then test with openssl verify.
And without knowing what's exactly in /etc/freeradius/certs_eaptls or etc/freeradius/certs it's next to impossible to say anything. As it doesn't seem to work you seem to have either the wrong certificates or the wrong hashes or missing hashes or...
It's also extremely difficult to understand if you don't post what the content of the crt files is exactly.
Does rad.crt contain only the server certificate or the server certificate followed by the issuing chain excluding the root ca?
Same here:
network={ key_mgmt=WPA-EAP eap=TLS identity="blabla at domain.tld" ca_cert="/etc/ssl/certs/chain.crt" client_cert="client.crt" private_key="client.key" private_key_passwd="blabla" }
Guessing from the name chain.crt, it's a chain (containes intermediate cas) and not a collection of root CAs. That is also a flawed approach and no useful test because generally you only pin root CAs on clients because that's all they really know.
The TLS server delivers the chain exluding the root. The TLS client know the (preinstalled) root CAs and can verify the server chain.
I did run strace on "openssl verify" and I saw very clearly what files are examined for trusted CAs (it extracts IssuerName from client cert, hash it and then search for filename with that hash in trusted CA stores).
Again without posting the exact output, assuming here that "trusted CA stores" is /usr/lib/ssl/certs, that's to be expected because openssl verify is using the default path.
I tried that same approach with "strace freeradius -fxxx" + "eapol_test ..." and did not find any similar output (just accessing server certificate and key but not any other *.PEM).
freereadius is not using probably not the default path, thus it's a completely different outcome. But if you are using strace you should see what it is really using and accessing.
Regarding the debug output: that's it. All relevant attributes from client certificate are shown and then bump "Warning: Certificate chain - 1 cert(s) untrusted", "Warning: (TLS) untrusted certificate with depth 0".
And if you are using strace you should also see what paths freereadius is trying to verify the certificate.
So unless you really post the full outputs and configs and show the full content of that directory and what those certificates really contain, that's kind of all someone can say from the outside.
You claim you did everything right with now way for us to verify.
Thus use the debug output and the strace and find out what's really happening. You can see from the strace what files it tries to open...
-Gerald
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 8, 2023, at 11:41 AM, MH <h33927318@gmail.com> wrote:
FreeRadius debug log says that certificate is untrusted. I don't know what are conditions which result in this decision. As I wrote earlier, I did not find any other openat(), so I think there were no other CA checks in chain (b6296c9d.0 contains intermediate CA).
Each file in the ca_path must contain only one certificate. This is an OpenSSL limitation. The ca_path directory must contain all CA certificates used to create the client certificate. If you put multiple CAs into one file, then you must use the "ca_file" configuration for FreeRADIUS, not "ca_path". This is all documented. Alan DeKok.
On 08.06.23 11:41, MH wrote:
Well, I am not very familiar with strace but I was able to use it in a way where I got this output "openat(AT_FDCWD, "/etc/freeradius/certs/b6296c9d.0", O_RDONLY) = 4". FreeRadius config is "ca_path = ${certdir}" and certdir is "/etc/freeradius/certs". File "b6296c9d.0" contains CA of client certificate. I don't know what return value 4 means.
4 is simply the number of the file descriptor. It's used to access the file until it is closed "close(4)"
I tried "sudo -u freerad cat "/etc/freeradius/certs/b6296c9d.0" and file is readable.
Obviously, because the return code of openat would have been "-1" instead of "4" if radiusd cannot access the file.
There are no other relevant openat() in strace.
You need to look at all open calls, not only at the openat calls. And as you refuse to post the hard facts like the exact strace command you are using, we can only hope you are doing it right...
FreeRadius debug log says that certificate is untrusted. I don't know what are conditions which result in this decision. As I wrote earlier, I did not find any other openat(), so I think there were no other CA checks in chain (b6296c9d.0 contains intermediate CA).
openssl verify -CAfile /etc/freeradius/certs/b6296c9d.0 /root/eapol/client.crt /root/eapol/client.crt: OK
Again: this test is pointless. It doesn't mean anything. If you don't use the command I wrote before, you cannot test what actually happens. If b6296c9d.0 is really pointing to a file with a single intermediate CA the output should be error 2 at 1 depth lookup: unable to get issuer certificate error /root/eapol/client.crt: verification failed if it was working the way you think it does. Thus, the OK is only showing you that the verify command is still using the system certificates. It's not working the way you think. It does not work like freeradius does. My guess (because of the total lack of useful information...) would be that openssl verify /root/eapol/client.crt and openssl verify -CAfile /dev/null /root/eapol/client.crt would just get you a OK as well. So basically, all your openssl verify tests are useless... -Gerald
št 8. 6. 2023 o 8:28 Gerald Vogt <vogt@spamcop.net> napísal(a):
On 08.06.23 07:37, MH wrote:
As I wrote in my first post, "openssl verify" command outputs that client certificate is trusted. I think that without specifying "-CAFile" in "openssl verify" it looks for trusted CAs in default locations. So it works with or without -CAFile (i.e default OS system CA store and custom CA store).
You forgot -CApath. That's still on the default, thus you are always using the system path.
The name of the option is also CAfile, not CAFile. It's so much easier to really know what you are doing if you post the exact command and the exact output. Because otherwise it's always a guess if you really do what you claim to do...
I expect FreeRadius does the same since it uses OpenSSL.
That's an odd expectation. You have configured
cadir = ${certdir}/certs_eaptls private_key_file = ${certdir}/rad.key certificate_file = ${certdir}/rad.crt auto_chain = no
Assuming that's really the complete relevant configuration (and you do not have ca_file nor ca_path configured) then you don't verify certificates against a file but a path. Thus
$ openssl verify -no_CAfile -noCAstore -CApath .../certs_eaptls client.crt
should be the command to test. Testing against a file but using a path is kind of futile.
All CA certificates (there is also an intermediate certificate) are in /etc/freeradius/certs, /etc/freeradius/certs_eaptls and also /usr/lib/ssl/cert.
That doesn't really help either. If you put them in various dirs, some you have configured and some are system default paths, and then test with openssl verify.
And without knowing what's exactly in /etc/freeradius/certs_eaptls or etc/freeradius/certs it's next to impossible to say anything. As it doesn't seem to work you seem to have either the wrong certificates or the wrong hashes or missing hashes or...
It's also extremely difficult to understand if you don't post what the content of the crt files is exactly.
Does rad.crt contain only the server certificate or the server certificate followed by the issuing chain excluding the root ca?
Same here:
network={ key_mgmt=WPA-EAP eap=TLS identity="blabla at domain.tld" ca_cert="/etc/ssl/certs/chain.crt" client_cert="client.crt" private_key="client.key" private_key_passwd="blabla" }
Guessing from the name chain.crt, it's a chain (containes intermediate cas) and not a collection of root CAs. That is also a flawed approach and no useful test because generally you only pin root CAs on clients because that's all they really know.
The TLS server delivers the chain exluding the root. The TLS client know the (preinstalled) root CAs and can verify the server chain.
I did run strace on "openssl verify" and I saw very clearly what files are examined for trusted CAs (it extracts IssuerName from client cert, hash it and then search for filename with that hash in trusted CA stores).
Again without posting the exact output, assuming here that "trusted CA stores" is /usr/lib/ssl/certs, that's to be expected because openssl verify is using the default path.
I tried that same approach with "strace freeradius -fxxx" + "eapol_test ..." and did not find any similar output (just accessing server certificate and key but not any other *.PEM).
freereadius is not using probably not the default path, thus it's a completely different outcome. But if you are using strace you should see what it is really using and accessing.
Regarding the debug output: that's it. All relevant attributes from client certificate are shown and then bump "Warning: Certificate chain - 1 cert(s) untrusted", "Warning: (TLS) untrusted certificate with depth 0".
And if you are using strace you should also see what paths freereadius is trying to verify the certificate.
So unless you really post the full outputs and configs and show the full content of that directory and what those certificates really contain, that's kind of all someone can say from the outside.
You claim you did everything right with now way for us to verify.
Thus use the debug output and the strace and find out what's really happening. You can see from the strace what files it tries to open...
-Gerald
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
openssl verify -no-CAfile -no-CAstore -CApath /etc/freeradius/certs /root/eapol/client.crt /root/eapol/client.crt: OK openssl version OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022) št 8. 6. 2023 o 12:29 Gerald Vogt <vogt@spamcop.net> napísal(a):
On 08.06.23 11:41, MH wrote:
Well, I am not very familiar with strace but I was able to use it in a way where I got this output "openat(AT_FDCWD, "/etc/freeradius/certs/b6296c9d.0", O_RDONLY) = 4". FreeRadius config is "ca_path = ${certdir}" and certdir is "/etc/freeradius/certs". File "b6296c9d.0" contains CA of client certificate. I don't know what return value 4 means.
4 is simply the number of the file descriptor. It's used to access the file until it is closed "close(4)"
I tried "sudo -u freerad cat "/etc/freeradius/certs/b6296c9d.0" and file is readable.
Obviously, because the return code of openat would have been "-1" instead of "4" if radiusd cannot access the file.
There are no other relevant openat() in strace.
You need to look at all open calls, not only at the openat calls.
And as you refuse to post the hard facts like the exact strace command you are using, we can only hope you are doing it right...
FreeRadius debug log says that certificate is untrusted. I don't know what are conditions which result in this decision. As I wrote earlier, I did not find any other openat(), so I think there were no other CA checks in chain (b6296c9d.0 contains intermediate CA).
openssl verify -CAfile /etc/freeradius/certs/b6296c9d.0 /root/eapol/client.crt /root/eapol/client.crt: OK
Again: this test is pointless. It doesn't mean anything. If you don't use the command I wrote before, you cannot test what actually happens. If b6296c9d.0 is really pointing to a file with a single intermediate CA the output should be
error 2 at 1 depth lookup: unable to get issuer certificate error /root/eapol/client.crt: verification failed
if it was working the way you think it does. Thus, the OK is only showing you that the verify command is still using the system certificates. It's not working the way you think. It does not work like freeradius does.
My guess (because of the total lack of useful information...) would be that
openssl verify /root/eapol/client.crt
and
openssl verify -CAfile /dev/null /root/eapol/client.crt
would just get you a OK as well.
So basically, all your openssl verify tests are useless...
-Gerald
št 8. 6. 2023 o 8:28 Gerald Vogt <vogt@spamcop.net> napísal(a):
On 08.06.23 07:37, MH wrote:
As I wrote in my first post, "openssl verify" command outputs that
client
certificate is trusted. I think that without specifying "-CAFile" in "openssl verify" it looks for trusted CAs in default locations. So it works with or without -CAFile (i.e default OS system CA store and custom CA store).
You forgot -CApath. That's still on the default, thus you are always using the system path.
The name of the option is also CAfile, not CAFile. It's so much easier to really know what you are doing if you post the exact command and the exact output. Because otherwise it's always a guess if you really do what you claim to do...
I expect FreeRadius does the same since it uses OpenSSL.
That's an odd expectation. You have configured
cadir = ${certdir}/certs_eaptls private_key_file = ${certdir}/rad.key certificate_file = ${certdir}/rad.crt auto_chain = no
Assuming that's really the complete relevant configuration (and you do not have ca_file nor ca_path configured) then you don't verify certificates against a file but a path. Thus
$ openssl verify -no_CAfile -noCAstore -CApath .../certs_eaptls client.crt
should be the command to test. Testing against a file but using a path is kind of futile.
All CA certificates (there is also an intermediate certificate) are in /etc/freeradius/certs, /etc/freeradius/certs_eaptls and also /usr/lib/ssl/cert.
That doesn't really help either. If you put them in various dirs, some you have configured and some are system default paths, and then test with openssl verify.
And without knowing what's exactly in /etc/freeradius/certs_eaptls or etc/freeradius/certs it's next to impossible to say anything. As it doesn't seem to work you seem to have either the wrong certificates or the wrong hashes or missing hashes or...
It's also extremely difficult to understand if you don't post what the content of the crt files is exactly.
Does rad.crt contain only the server certificate or the server certificate followed by the issuing chain excluding the root ca?
Same here:
network={ key_mgmt=WPA-EAP eap=TLS identity="blabla at domain.tld" ca_cert="/etc/ssl/certs/chain.crt" client_cert="client.crt" private_key="client.key" private_key_passwd="blabla" }
Guessing from the name chain.crt, it's a chain (containes intermediate cas) and not a collection of root CAs. That is also a flawed approach and no useful test because generally you only pin root CAs on clients because that's all they really know.
The TLS server delivers the chain exluding the root. The TLS client know the (preinstalled) root CAs and can verify the server chain.
I did run strace on "openssl verify" and I saw very clearly what files are examined for trusted CAs (it extracts IssuerName from client cert, hash it and then search for filename with that hash in trusted CA stores).
Again without posting the exact output, assuming here that "trusted CA stores" is /usr/lib/ssl/certs, that's to be expected because openssl verify is using the default path.
I tried that same approach with "strace freeradius -fxxx" + "eapol_test ..." and did not find any similar output (just accessing server certificate and key but not any other *.PEM).
freereadius is not using probably not the default path, thus it's a completely different outcome. But if you are using strace you should see what it is really using and accessing.
Regarding the debug output: that's it. All relevant attributes from client certificate are shown and then bump "Warning: Certificate chain - 1 cert(s) untrusted", "Warning: (TLS) untrusted certificate with depth 0".
And if you are using strace you should also see what paths freereadius is trying to verify the certificate.
So unless you really post the full outputs and configs and show the full content of that directory and what those certificates really contain, that's kind of all someone can say from the outside.
You claim you did everything right with now way for us to verify.
Thus use the debug output and the strace and find out what's really happening. You can see from the strace what files it tries to open...
-Gerald
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 8, 2023, at 7:37 AM, MH <h33927318@gmail.com> wrote:
As I wrote in my first post, "openssl verify" command outputs that client certificate is trusted.
That doesn't matter. The "openssl verify" command is looking in different directories for the CA certs. Your posts make this clear. If you give the "openssl" command the same ca path / cert files that you give FreeRADIUS, then the command will return the same result as FreeRADIUS. Because both of them use the same underlying OpenSSL APIs. This isn't magic.
I think that without specifying "-CAFile" in "openssl verify" it looks for trusted CAs in default locations. So it works with or without -CAFile (i.e default OS system CA store and custom CA store). I expect FreeRadius does the same since it uses OpenSSL.
I see... so you configured FreeRADIUS with an explicit CA path, pointers to cert files, etc. but you don't expect it to use those? Instead, you expect it to look in other directories? That's a very strange expectation. FreeRADIUS doesn't use the OS defaults for CA paths, because doing so would be wrong. A little bit of thinking about the subject will educate you as to why this is so.
I did run strace on "openssl verify" and I saw very clearly what files are examined for trusted CAs (it extracts IssuerName from client cert, hash it and then search for filename with that hash in trusted CA stores). I tried that same approach with "strace freeradius -fxxx" + "eapol_test ..." and did not find any similar output (just accessing server certificate and key but not any other *.PEM).
Regarding the debug output: that's it.
No, that's not it. There's a lot more in the debug output than what you posted. But since you clearly know more than us, and you have no intention of following the documentation or our advice, I think you're on your own. You clearly have the skills to fix this, and we don't. i.e. I've never understood the psychology of asking people for help, and then arguing with them about the answers. It's bizarre. Alan DeKok.
participants (3)
-
Alan DeKok -
Gerald Vogt -
MH