FreeRADIUS EAP-TLS Auth. Issues

[Alan DeKok]

On Jan 24, 2024, at 3:22 AM, Gerald Vogt <vogt at spamcop.net> wrote:
> 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.

  Patches are welcome.

  This is an open source project.  While myself and the rest of the team do a lot of work, our resources aren't infinite.  What would be appreciated much more than "you're wrong" is patches to fix it.

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

  Which is why OpenSSL provides for a CA directory.  The hope is that OpenSSL can figure things out, by being passed the right set of parameters.

  Sadly, this isn't the case.

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

  It would be productive to supply patches which correct documentation errors. 

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

  Oddly enough, FreeRADIUS calls the same OpenSSL API calls that the browsers use.  The theory is that by supplying a trusted root CA, OpenSSL can then validate the chain, including any intermediate CA.

  The main issue with FreeRADIUS is that the default configuration assumes that both the server cert and the client certs are derived from the same root CA.  When that isn't the case, it becomes more difficult.

  Happily, source code is available.  It should be possible for an enthusiastic and positive person to add new configuration parameters, and have the server call different OpenSSL APIs to add new behavior.  Then, also to add documentation, and update the existing documentation.

  Until that happens, v3 won't change.

  For v4, we've substantially reworked the TLS code and configuration.  If that still doesn't meet your needs, we again welcome patches and documentation updates.

  Alan DeKok.