EAP-TLS unable to get local issuer certificate

[MH]

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