EAP-TLS unable to get local issuer certificate

[Gerald Vogt]

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 at 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