FreeRADIUS EAP-TLS Auth. Issues

[Alan DeKok]

On Jan 24, 2024, at 2:16 PM, Gerald Vogt <vogt at spamcop.net> wrote:
> I have explained several points in my second message in the ticket.

  Which I had responded to, but OK...

>                #  If ca_file (below) is not used, then the
>                #  certificate_file below SHOULD also include all of
>                #  the intermediate CA certificates used to sign the
>                #  server certificate, but NOT the root CA.
> 
> O.K. If ca_file is not used, I put the server cert following by the issuing CAs in order except the root ca into certificate_file.

  That will allow the server to present it's certificate and CA to the client, when the client connects.  That's all true.

>                #  When using "ca_file" or "ca_dir", the
>                #  "certificate_file" should contain only
>                #  "server.pem".  And then you may (or may not) need
>                #  to set "auto_chain", depending on your version of
>                #  OpenSSL.
> 
> O.K. In the other case the ca_file or ca_dir are used (i.e. defined) certificate_file should only contain the server certificate. It is a "should" but the average user will hopefully the developers advice.

  Yes.  If there are multiple CAs, then they can all go into a directory, and OpenSSL will figure it out.

  That should be a hint as to the real issue:  The FreeRADIUS configuration mirrors the OpenSSL APIs.  If something weird or magic happens, it's almost always because of OpenSSL.

>                #  Trusted Root CA list
>                #
>                #  This file can contain multiple CA certificates.
>                #  ALL of the CA's in this list will be trusted to
>                #  issue client certificates for authentication.
> 
> So now it starts: I want to use client certificates. Thus, if I do I can define ca_file.

  The comments here are fairly clear.

> Now if I do that, it means I am using "ca_file", i.e. the certificate_file should contain only the server certificate, not the issuing CAs.

  Yes.

> This also means, that "ALL of the CAs in this list will be trusted to issue client certificates".

  Yes.  That's the reason to list multiple CAs: you want to authenticate client certs issued by different CAs.

> This means, if my client certs and server certs use different CAs I cannot distinguish them, e.g. my server cert could be used for client certificate authentication (if it the server has the attributes set). Something I don't want.

  So... don't issue client certs from the server CA?  Presumably someone is in charge of it, and can be convinced to do the right thing.

  If you don't trust the CA admins to issue client certs correctly, then no amount of technical changes will fix a political issue.

> So what now? Do I deviate from the "should contain only server.pem"? Or it is wrong to use "ca_file"?

  Do what the documentation says.  And don't issue client certs from the server CA.  The problem is then fixed.

> Second confusion: it says "Trusted Root CA list". It says "Root CA". That does not include intermediates CAs.

  It includes the intermediate CAs.

 But in general if you have multiple CAs, just put them into a directory, and let OpenSSL figure it out.

> But without the intermediates, you cannot create a chain from the (server cert only) certificate_file nor can you verify client certs issued by intermediates.
> 
> So what now? So is this really only a root ca list and the intermediates must go somewhere else? Or is it simply a trusted ca list?

  This is where I say "try it and see".  And then perhaps submit a GitHub PR to address this issue.  That's a productive approach.

  What isn't productive is to spend hours arguing "the documentation is bad" instead of figuring things out, and fixing it.

>                #  In general, you should use self-signed
>                #  certificates for 802.1x (EAP) authentication.
>                #  In that case, this CA file should contain
>                #  *one* CA certificate.
> 
> O.K. Again, if I follow that advice, use self-signed certificates for EAP, thus put only one CA cert into the ca_file, it also requires my server cert to be issued by that CA, when I follow the instructions before.

  It's a suggestion, not a mandate from heaven written in stone.

  If you want to use multiple CAs, you can do so.  Nothing prevents you from doing this.  The documentation explains how to do this.

  The documentation also suggests best practices.  You're free to follow them, or to do something else.

>                #
>                #  Directory where multiple CAs are stored.  Both
>                #  "ca_file" and "ca_path" can be used at the same time.
>                #
> 
> After all the explanations before telling me what to do when, this now only tells me ca_path is a list of CAs.
> 
> This is unclear: where is this used? Does the ca_file comment applies and this is a place for (root?) CAs used for client certificates?

  I'm not sure why there's any confusion.  CAs go either into ca_path, or ca_file.  What's the issue?

> Or is it just the same like ca_file but with certs stored in a directory?
> 
> Above first it says "ca_file (below) is not used" and later it says "When using "ca_file" or "ca_dir",". Is this distinction intentionally or is it simply an error of omission?

  I don't know what the confusion is.  You're given multiple options for configuring things.  The documentation explains what each option does, and how they interact with each other.

  The issue seems to be that the documentation suggests you don't always need to use ca_file, and then you see this as somehow a contradiction.  Because other documentation says you can use ca_file and/or ca_path.

  There's no issue.

> I am only reading what's in the comments and am trying to figure out how to correctly configure it to get a working tls server with the chain attached and allowing for client certificates.

  "correctly configure" means "it works".

  What doesn't work is reading the documentation, and then throwing your hands up in the air, and loudly proclaiming "it's garbage".   Which is quickly followed by "You guys need to fix it.  I refuse to contribute".

  Anyone with a little bit of self awareness should see how that is not going to be taken well.

> That's what I wrote in the issue, which you mostly ignore in your response.

  That's not true of course.  But I guess I've gotten used to that response.

> In the end, I have configured certificate_file with the server cert followed by the issuing ca chain and put all ca root and intermediate ca certs for client certificates into ca_file, so explicitly not doing what I "should" do.

  No.  The documentation doesn't say that configuration is forbidden.  It explicitly says it's allowed.

> The texts in the comments is somewhat like a logical riddle to solve, you'll  have to try all possible combinations until you'll find one which doesn't end in a contradiction.

  Welcome to OpenSSL and TLS hell.  You're blaming us for OpenSSL weirdness.

  You might as well drive your car into an inner-city pedestrian area, and then complain that GM doesn't give you detailed documentation on downtown LA.  It's rather missing the point.

> Well, if the text is unclear and I don't know what the text really should be because it's unclear how everything is used exactly, I cannot give you a better text nor anything else "actionable". I can only point out, describe, explain the confusion.

  Substantial parts of your messages were little more than "the documentation is wrong / unclear".  Despite repeated attempts to get you to explain, you refused.  And instead of explaining, you started complaining about how "arrogant" I am.

  That's not an approach intended to make friends.

> At least for a lot of web servers running httpd or nginx, or postfix mail servers I never found myself in a situation that was unclear or was magically not working the way I expected it and how it was documented...

  Have you configured them with multiple CAs and multiple client certs?  I suspect not.

https://nginx.org/en/docs/http/configuring_https_servers.html

  Contains nothing about multiple CAs, and nothing about client certs.

  So you're comparing apples to oranges here.  If you configure FreeRADIUS with one CA, then it's just as easy to configure as nginx.

> It's you who is refusing and simply closed the issue before. It was a very clear sign to me that you are absolutely not interested in my feedback... It's not blame. You did close my issue. That's just what it is.

  As I've explained repeatedly, I'm interested in *good* feedback.  I have 25 years of proven history of accepting feedback from hundreds of people.  People who can clearly explain their issues and their requirements.

  The conclusion then is not that I don't want feedback, but (as I've said over and over) I want *good* feedback.  Yet somehow you've concluded that I'm the problem, and that I'm refusing your feedback because I'm arrogant.

  All available evidence shows the opposite.

> It is what it is... I continue to contribute in the way I do, if you like it or not. You can complain about it or not. Or maybe I don't contribute anymore. There are a many other projects where they welcome my insight and contribution even if it is sometimes difficult to get a common understanding of things. And there is not this immediate hostility.

  I can't tell you how many times I've seen that response when I ask people to do something positive.  "Oh yeah?  You're mean!  I WOULD contribute, but I can't because you people are MEAN!"

  That response is *always* from people who don't contribute, and who don't intend to contribute.  It's like a poker "tell" for people who are more interested in complaining than making the world better.

  You're welcome to use FreeRADIUS.  You're welcome to contribute patches.  But I won't hold my breath.

  Alan DeKok.