FreeRADIUS EAP-TLS Auth. Issues

[Gerald Vogt]

There is little you can do about this at the moment. I have wrote a 
while ago that it's conceptually flawed to mix ca path/file 
configuration for the server side (i.e. how the freeradius tls server 
builds and presents its chain) with the ca path/file configuration for 
the client verification. That already makes it hard.

The "reject_unknown_intermediate_ca" option which I guess actually 
should be named "reject_untrusted_intermediate_ca" rejects intermediate 
ca certificates which are not trusted, i.e. not in the trust store.

openssl at some point started to distinguish between trusted and 
untrusted certificates to help the dilemma that before anything in a CA 
file or CA path was trusted (aka a truststore), i.e. any intermediate ca 
certificate was trusted because it was in there, even though you didn't 
really know anything about that intermediate ca except that it's in your 
chain.

Now, with untrusted certificates you can verify certificates through a 
chain of intermediate cas to a trusted root without explicitly trusting 
each intermediate.

A certificate is successfully verified if there is a known chain from 
the certificate to a root ca in the trust store. Only the root ca is 
explicitly trusted. All other intermediate ca certificates are per se 
untrusted. The validity of the chain and the trust through the chain is 
established by the root ca in the trust ca.

Thus, an untrusted intermediate ca certificate in the chain is 
acceptable. Just the chain must verify to a root ca in the trust store.

The trouble is how to configure it properly in freeradius as it only has 
certificate_file, ca_file and ca_path, and their mixed used for the tls 
server certificate (chain) and the tls client verification. The comments 
in the configuration files on those options being misleading or 
inaccurate in some aspects, too.

Thus, set "reject_unknown_intermediate_ca = no". Technically, the whole 
option is properly not needed. If set to "yes", it'll break chains which 
are O.K. only because an intermediate ca certificate is not in the trust 
store. But that's not an issue as long as the root ca is in the trust store.

It's the same way any browser works: there are trusted root cas and the 
chain validation of any webserver is built from there, learning the 
intermediate CAs on the way without giving them explicit trust.

Otherwise, I think you have to put all the intermediate CAs for client 
verification into the certificate_file which must also contain the 
server certificate and chain, because I think that's ultimately what is 
currently used as universal trust store in freeradius. But I haven't 
tested that lately.

I know that you still need "reject_unknown_intermediate_ca = no" if you 
put only the server cert and chain into certificate_file and all root 
and intermediate cas for client verification into ca_file (ca_path 
commented out), regardless what the comments before ca_file says...

Cheers,

Gerald

On 24.01.24 06:52, Andrew Lowther wrote:
> FWIW, I had the same experience using FreeRADIUS 3.2.3 on Ubuntu
> 22.04.  EAP-TLS authentication would always fail when using the
> configuration
> 
> reject_unknown_intermediate_ca = yes
> 
> When the server ran in debug mode it would print something like
> 
> Warning: Certificate chain - 1 cert(s) untrusted
> Warning: (TLS) untrusted certificate with depth [1] subject name
> /CN=IntermediateCA
> Warning: (TLS) untrusted certificate with depth [0] subject name /CN=Client
> Auth: tls: There are untrusted certificates in the certificate chain.
> Rejecting.
> 
> The server debug output will print all the certificates in the chain
> that the client provides.  Removing the Intermediate CA from the
> server could change the output to
> 
> Warning: Certificate chain - 2 cert(s) untrusted
> 
> but there was always at least 1 cert(s) untrusted.
> 
> My suspicion is that the Intermediate is not causing the problem.  I
> suspect the call to X509_STORE_CTX_get0_untrusted returns the leaf
> certificate that the client provided as untrusted.    I did not
> understand the code well enough to confirm my suspicion.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html