On 24.01.24 18:19, Alan DeKok wrote:
On Jan 24, 2024, at 11:33 AM, Gerald Vogt <vogt@spamcop.net> wrote:
So I have made suggestions on how to improve this, how to have clear and distinguished configuration parameters for the configuration of the tls server and the tls client verification.
I'll have to disagree. You were asked repeatedly in the GitHub issue to explain. The responses were not actionable.
Oh goodness. You are persistent. I don't know how else to explain how something is confusing or misleading expect describing the confusion that there is.
I have pointed out how the comments for the configuration parameter are confusing or misleading.
What is confusing? What is misleading? I've asked you for details. In response, I get long descriptions which aren't actionable.
I have explained several points in my second message in the ticket. # 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. # 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. # 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. 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. This also means, that "ALL of the CAs in this list will be trusted to issue client certificates". 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 what now? Do I deviate from the "should contain only server.pem"? Or it is wrong to use "ca_file"? Logical decisions based on the information given lead me here. Now I have to track back to find a descision which gets me what I want. Second confusion: it says "Trusted Root CA list". It says "Root CA". That does not include intermediates CAs. 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? # 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. # # 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? 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 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. That's what I wrote in the issue, which you mostly ignore in your 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. 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. At the same time, because it's unclear to me what each parameter really does and where it's used, it's difficult to give a suggestion how it would be better. I do not know how to describe the issue, except "long descriptions". I could translate the text into logical expression though the "should" makes it hard.
If it's so easy and so clear, why don't you write it simply into the documentation? If I point out discrepancies or what's unclear but you shut it down.
I didn't say it was easy and clear. I said that you need to describe exactly what's wrong it the existing documentation. In response, I got nothing actionable.
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.
In case it wasn't clear, the documentation is as clear as we can make it. We've put literally decades into understanding every possible situation for FreeRADIUS, including TLS. Yet despite that, OpenSSL and TLS are still magic. It's still not clear to us why some things work and some don't.
Well, that's bad. I cannot tell what you have found which "works" or "don't", but generally I don't see the "magic" you have found, at least when it's related to the certificate handling. The TLS server cert and it's chain is, well, static. For the client certificate you have to verify the client certificate which usually can be simulated with "openssl verify" using the right parameter set of -{no,}CA{file,path,store} -{un,}trusted. 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...
But you don't accept that. You're refusing to do the work to figure it out, while still demanding that we do that work. And anything you do figure out is secret, and you're not going to share.
I am trying to figure out what "magic" you have implemented with those configuration parameters, but it's difficult and you are not really helping to clear that up. So I can only guess... So basically, I could repeat those exact three sentences, because that's how it seem to me.
That attitude is highly inappropriate.
I could repeat that sentence, too. I try to figure it out, how it really works, and just give me an attitude...
Also, assuming that people know that the option "ca_dir" is used as openssl "CApath", thus requires the hashes, well... "We do not include ... all of OpenSSL documentation". Let the dumb user figure it out themselves. Why should the docs indicate that ca_dir is CApath and requires c_rehash (did FR 2.x mentioned c_rehash?)
If only there was some kind of github thing where you could explanations to the documentation, and have them included in the server.
And that's what you like to do, too, ironically ignoring lots of explanations and than picking on one single point. If I suggest something I'd rather do that in the context of the whole process and not just a breadcrumb only because that's what you understood.
I did a bunch of stuff.
It works for me. And I think the way I did it I think it only works the way I expect it and that there are not side effects which are allowed.
So everything you did is secret, and you're not going to document what you did.
Wonderful. If you want a reason why you think the documentation is bad, it's because people figure things out, and then refuse to contribute.
As I wrote multiple times before and you didn't seem to read: I can only contribute with a suggestion of a better text, if I understand how it works exactly. You don't want to help with that. Nor are you even trying to understand the confusion of those contradictory statements in the docs. I can write a suggestion for the docs based on how I use it now. But I don't know if it's correct because I don't know where each parameter is used exactly. It works for me and I hope that it doesn't allow more clients certs then I want, but I cannot tell for sure. However, the way I have configured it is mostly in direct contradiction to what in those comments. That adds to my hesitation to suggest a text. I assume that the current text has been added there for a reason and is or was accurate at some time. Or the current text is accidentally incorrect, but noone noticed. I am trying to figure out what's right.
The documentation is unclear. I have to guess what the documentation means. You ask me for documentation updates. How am I supposed to give you a documentation update from some guesses? That documentation won't get any better, it's just another guess.
Excuses. You can document a "howto": This is what I did, and this is what happens, and this is what works.
Again: if I do that I want to give an accurate and correct description. I don't think a howto is helpful which contradicts the docs or another howto. People will just wonder more, why it's different or if it's different cases. If I do something I do it right. I don't really think it's helpful to write a howto "ignore what's in the docs because it's wrong, but do it this way instead..."
All of your blaming me here is just excuses so that you to find reasons to *not* contribute.
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. My current understanding on the use of those parameters is limited and the current docs are confusing. You are not helping to clear this confusion but you want me to write something. If I write something I want it to be accurate. I don't really see the point of changing those texts into something I guess what it is, because maybe that's not accurate either.
If that's a problem for you or doesn't fit your standards, well, no need to repeat your "patches are welcome"...
My general response of "patches are welcome" is to people who give vague complaints, and then demand that everyone *else* do work.
"Statement A contradicts statement B" isn't vague. You demand from me to do the work to solve this contradiction.
For people who give clear descriptions of problems, I push in fixes. Documentation updates, code changes, etc. Anyone who's paid attention to the list will see hundreds of examples of people saying "this isn't clear", followed be me pushing a patch minutes later.
The docs for those parameters aren't clear. I do not know how to give a clearer description of that. If you want me to provide a documentation update, I need to understand what it's doing exactly and not based on my assumptions and guesses of how and where those parameters may be used...
Yet some people always find a reason to complain, and reasons why they should never contribute. And it's never their fault. Hence my hostility to that entitled and negative attitude.
The only negative attitude here comes from you. You quickly fall into hostility and quickly shut it down. And it was you who complained about my explanation on how to use reject_unknown_intermediate_ca in this thread and why it is needed. It's the situation how it is and hopefully the solution for the issue the user had. I understand that it (probably) works different with 4.x. I don't really expect larger changes to go into 3.2 either, if 4.x is in the making. So it is as it is. I then responded to your complaint. I have contributed to the other user and this list. So I really find this comment inappropriate. I do contribute. You just don't like my contributions for whatever reason. You just don't want to understand what I write. It probably doesn't matter how often and in what way I try to explain it. You want a clear explanation of something which isn't clear at the moment... And considering my repeated attempts to explain the situation and how it's difficult to suggest a better text if it is unclear how it exactly works. So negating all my contributions to "never" isn't really nice either. I know you can go into the technicality that you wrote "some people", but in the context it's obvious that you apply the generic to me, because otherwise it wouldn't make much sense. I didn't complain. I understand that you simply don't like me or the way I explain and write my points. I understand that you consider this completely and totally my fault. I understand that you think this entitles you to quick hostility and shutting people down. I understand that you think it is no fault of yours at all... 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. So like it or not... Cheers, Gerald