EAP-TLS unable to get local issuer certificate

[MH]

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 at 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 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
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>