EAP-TLS unable to get local issuer certificate

[Gerald Vogt]

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