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