On Jan 23, 2024, at 7:59 AM, SENECAUX Ludovic <Ludovic.SENECAUX@lenord.fr> wrote:

I'm having an issue with FreeRADIUS 3.2.3 and the EAP module. It doesn't take into account my private PKI.

The server needs to be configured with the CA for any private PKI.

I have to set the reject_unknown_intermediate_ca parameter to no for EAP-TLS authentication to work. I have no issues with FreeRADIUS 3.0.x

I don't think we changed anything about certificate handling for CAs. All of this magic is handled by OpenSSL.

ca_file = ${cadir}/chain.pem

This file should contain the full CA chain in order. See the comments in mods-available/eap.

lrwxrwxrwx. 1 root root 17 Jan 23 12:17 3377b39c.0 -> subca.pem lrwxrwxrwx. 1 root root 18 Jan 23 12:17 72f73b82.0 -> rootca.pem -rw-r-----. 1 root radiusd 4111 Jan 23 10:16 chain.pem -rw-r-----. 1 root radiusd 1818 Jan 23 10:17 rootca.pem -rw-r-----. 1 root radiusd 2293 Jan 23 10:17 subca.pem

The rootca and subca should be OK. The ca_path references them. You may need to set "auto_chain = yes". See mods-available/eap.

... Certificate chain - 1 cert(s) untrusted (TLS) untrusted certificate with depth [1] subject name /CN=SubCA (TLS) untrusted certificate with depth [0] subject name /CN=device

Which certificates are those for? rootca.pem? subca.pem? Alan DeKok.

On Jan 23, 2024, at 8:51 AM, SENECAUX Ludovic <Ludovic.SENECAUX@lenord.fr> wrote:

I set "auto_chain = yes" ; the result is the same.

...

ca_file = ${cadir}/chain.pem This file already contains rootca and subca certificates.

OK, that's good.

...

...

Certificate chain - 1 cert(s) untrusted (TLS) untrusted certificate with depth [1] subject name /CN=SubCA (TLS) untrusted certificate with depth [0] subject name /CN=device Which certificates are those for? rootca.pem? subca.pem?

The device cert is signed by subca, which is signed by rootca.

Except the rootca isn't printed out in that list. So for some reason it's not loading the rootca. Alan DeKok.

On Jan 23, 2024, at 9:54 AM, SENECAUX Ludovic <Ludovic.SENECAUX@lenord.fr> wrote:

I checked again my 2 radius servers ; if I set " reject_unknown_intermediate_ca = yes" : - 3.0.20 (PROD) : eap-tls auth. is ok - 3.2.3 (DEV): eap-tls auth. is broken

Same OS version, same OpenSSL version, same Radius config.

That's unfortunate. Looking at the two versions, the TLS code is in src/main/cb.c, and src/main/tls.c The "cb.c" file is identical to v3.0, other than some changes to the debug output. The "tls.c" file shows a few more differences, but those are largely debug output changes, or new features which don't affect certificate validation. I'd double-check the systems. If this the same machine and the two versions of FreeRADIUS are different, then the issue is FreeRADIUS. If the two systems are different (magically somehow), then maybe there's some other OpenSSL issue which is causing the difference. i.e. it's not enough to say "same version of OpenSSL". There's all kinds of magic going on behind the scenes that I'm not aware of, such as vendor patches to code, configuration, etc. Also, please check that you're running packages from http://packages.networkradius.com. If you're running packages supplied by the OS vendor, those are very often patched and different (i.e. broken) in odd ways. Alan DeKok.

On Jan 23, 2024, at 10:30 AM, SENECAUX Ludovic <Ludovic.SENECAUX@lenord.fr> wrote:

It is the same virtual machine.

OK.

I reinstalled FR 3.0.20, and I saw the "reject_unknown_intermediate_ca" parameter does not exist in this version. If I add this to eap configuration, it is not loaded during server starts.

Yes it doesn't exist in 3.0.

So, is the value 'yes' implicit in this branch ?

No. The default value is "no". You can check this by running the server in debug mode, and looking for that configuration. My suggestion is to add the root and intermediate CAs to the "certificate_file", along with the server cert. This configuration tells the server (and OpenSSL) that this particular root CA and this particular intermediate CA are trusted. Alan DeKok.

On Jan 23, 2024, at 10:49 AM, SENECAUX Ludovic <Ludovic.SENECAUX@lenord.fr> wrote:

...

My suggestion is to add the root and intermediate CAs to the "certificate_file", along with the server cert. This configuration tells the server (and OpenSSL) that this particular root CA and this particular intermediate CA are trusted. I already did that, but the issue is still there ...

For now, just set the flag. That reverts the behavior to v3.0. Alan DeKok.

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

Well, you'll probably understand that someone wouldn't want to make some bigger changes to the source, if someone hasn't written code in C for more than 20 years, and considering the way you shoot off replies of people here and on github, I'll surely expect any patch submitted being refused because there's something not the way you want it, not following some way or coding style which is somewhere probably documented in length. And adding new parameters and splitting the use of them to their proper causes is definitely not a two-line change. So please excuse me, if I don't want to spend time on something for which I am pretty sure will be mostly wasted time... And looking at https://github.com/FreeRADIUS/freeradius-server/blob/57325921a6c6526519d5d6d... it seems 4.x also uses a set of trusted certs in "chain" for the untrusted parameter of int X509_STORE_CTX_init(X509_STORE_CTX *ctx, X509_STORE *trust_store, X509 *target, STACK_OF(X509) *untrusted); I am very sorry, Gerald On 24.01.24 13:24, Alan DeKok wrote:

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

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

On 24.01.24 15:00, Alan DeKok wrote:

On Jan 24, 2024, at 8:44 AM, Gerald Vogt <vogt@spamcop.net> wrote:

...

Well, you'll probably understand that someone wouldn't want to make some bigger changes to the source, if someone hasn't written code in C for more than 20 years, and considering the way you shoot off replies of people here and on github, I'll surely expect any patch submitted being refused because there's something not the way you want it, not following some way or coding style which is somewhere probably documented in length.

It's certainly easier to criticize than to contribute.

One reason FreeRADIUS has become the de-facto RADIUS server world-wide is a consistent approach to documentation and code quality. There are any number of projects (or companies) which have failed because of the attitude of "just hack it until it works".

Insisting that code be good quality isn't an attempt to denigrate contributors as you imply. It's an attempt to ensure good engineering. You wouldn't live in a house which is slapped together by a people who don't care if the roof falls in, so why ask the same of a software product?

...

And adding new parameters and splitting the use of them to their proper causes is definitely not a two-line change.

No one said it was. However, it should be reasonably straightforward to describe what *should* be done. It's possible to open a GitHub issue, and type in text. Text which can describe at a high level what the configuration should look like, and how the functionality should behave.

I tried. You have closed the issue. You see my point? You consider opening an issue just as critique and refuse from the very beginning.

Nothing stops you from doing that, other than an attitude that you deserve to download FreeRADIUS for free, but it's inappropriate for you to be asked to contribute.

You can ask people to contribute, but you have to understand that there are only a few people who are really able to contribute patches. I cannot contribute. I don't have the technical knowledge to contribute. And you don't like the high level contributions, either, just as your reply to my extended explanation of the issue shows. I don't know how the full and complete and correct solution should look like. That would be something for discussion. But any solution to any problem starts IMHO with describing what the current problem is. But all you write in response is "supply patches", "source code is available". What you expect? Even suggesting "correct documentation errors" isn't that simple, because I mostly make assumptions about how a parameter is actually used from why I see in the debug logs. I try to follow the source code to some extend but it's not easy to do and I, too, have limited time at hands trying to figure something out which probably a developer already knows. So I cannot really correct documentation errors of parameters if I don't really know where that parameter is used. And thus, assuming the original text there was based on how it was or maybe even is used in parts, I cannot really give a better text because I would have to know the code much better. Thus, all I can do then is to give some hints on how to use the current parameters to get it properly working and give some explanations on why it may be that way.

At a high level, OpenSSL *should* do the right thing. It's given a directory of root CAs and intermediate CAs. It's given a client certificate signed by those CAs. Yet it can't figure out that the client certificate is signed by those CAs.

It's annoying, and we don't have infinite time to figure it out. The team is busy with large amounts of other work. The current behavior is OK for most people. And no one is willing to contribute fixes.

That is not true. I am willing to contribute fixes, however, I am not able to contribute fixes.

...

So please excuse me, if I don't want to spend time on something for which I am pretty sure will be mostly wasted time...

Yes. Your work might not succeed, so why even try?

Yes. If the person who evaluates your attempt, has a certain attitude to shoot everything down, you'll obviously ask yourself why should you even try. I am more than willing to help as I do in a lot of other projects, but I can always only contribute to the extent of my abilities (and the time I have).

...

And looking at

https://github.com/FreeRADIUS/freeradius-server/blob/57325921a6c6526519d5d6d...

it seems 4.x also uses a set of trusted certs in "chain" for the untrusted parameter of

int X509_STORE_CTX_init(X509_STORE_CTX *ctx, X509_STORE *trust_store, X509 *target, STACK_OF(X509) *untrusted);

Hmm, yes. You have time and energy to criticize, but none to contribute. i.e. the issue is attitude, not time.

Again: you just shoot down an possible issue I have noticed as critique. It's just pointless to discuss anything with you because your standard answer to most remarks are like that... So as you correctly state "the issue is attitude, not time". You just have the problem of acknowledging how your attitude is the issue to start with.

...

I am very sorry,

Apparently not.

I will still contribute to FreeRADIUS, even if others don't.

I'm just disappointed that there is a large group of people who feel that they are entitled to criticize something, but who express horror at being asked to contribute. If everyone behaved that way, then FreeRADIUS wouldn't exist, and you would be paying $2K a year for a commercial product.

You are disappointed that there is a large group of people who have suggestions how to improve something or who find issues in how things are, but who are not able to contribute significantly... And the attitude in your responses really kills off the last bit of willingness to help to the extent possible.

FreeRADIUS exists despite that attitude, not because of it.

As it does despite your attitude, but mostly, I guess, because there are not many alternatives. But I don't expect you to understand that your attitude towards others has a direct effect on how people are willing to participate or the lack of in that matter. We all have very limited time. I use freeradius and all that matters to me in that respect is that I get it to work the way I want it to. If I notice issues along that line I can point them out (that's not critique even if it feels like to you) and make some suggestions on how to improve that (which still isn't critique), mostly very high level at first because I don't work on my radius servers all the time. You can either pick that up, show some interest and start a discussion which could well go deeper, or you can simply be disappointed and tell people that they "have time and energy to criticize, but none to contribute", expecting them (between the lines) to provides fully finished code patches which you can review. Well. Again I am very sorry for wasting so much of your time (and mine in this mail) with "useless" discussions for which you most likely don't see how much you contribute to the problem you complain about. I would love to participate and contribute if it was welcomed and not just shot off... Sorry, Gerald

On 24.01.24 16:06, Alan DeKok wrote:

On Jan 24, 2024, at 9:44 AM, Gerald Vogt <vogt@spamcop.net> wrote:

...

I tried. You have closed the issue. You see my point? You consider opening an issue just as critique and refuse from the very beginning.

For the record, the issue is this: https://github.com/FreeRADIUS/freeradius-server/issues/5012

It has a long discussion where you were asked repeatedly to explain what's wrong with the current configuration / behavior, and to offer better suggestions. That didn't happen.

On the contrary, it's all in the initial message. I wrote what's the problem with the current configuration and why it's an issue to mix up use of ca files or paths for both server and client configuration. I have outlined, on a high, conceptual level what configurations are necessary or possible to cover all those aspects. I have also gave an example how it is does it httpd mod_ssl and that there is a good reason why they have separated it. 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. You basically answered that you can do the things that you want to do so what's wrong? It works. I have pointed out how the comments for the configuration parameter are confusing or misleading. I don't know, where exactly those parameters are used for. I can only read the comments and try to understand what the purpose is or how they map to the standard openssl parameters like for verify. So how do you think I should know when to put the server CAs into certificate_file and when not. Or when you can use ca_file. Or ca_path. Or both. Or only either. When using client certificates. Or when not using client certificates. It is unclear, what it does exactly. So expecting someone else to clarify the documentation is kind of futile. 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. Thus, if you write " It just takes a little bit of work", then that is not helpful if that work is required because it's unclear. You may as well end up with a configuration which works but accepts much more certificates then indented. The trouble is, most people won't notice that until there is a problem. Thus, as I write in the initial message of that issue: conceptually the tls server configuration and tls client verification are two completely different aspects which can rely on two completely different ca sets. Thus, conceptually it would be better separate those. But currently, if I understand correctly, the tls server can build its chain from ca_dir and at the same time the client verification can use ca_dir, too. 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?) You don't see how it's unclear. So why bother with anyone who finds it unclear? Not to mentioned that arr2036 also wrote "I found that extremely confusing and ended up redoing a lot of the validation logic manually." So really, I am not the only one...

So the reported problem ended up being "I don't understand how it works. I don't know how it should work. I don't know how to change it".

There is no action we can take to fix that. Which is why the issue was closed.

Yes, excellent move to shut down any attempt to clarify it. It is 'extremely confusing'...

...

Yes. If the person who evaluates your attempt, has a certain attitude to shoot everything down, you'll obviously ask yourself why should you even try.

A simple "git log" of the server shows that's not true. There are many, many, people who have contributed. But they take the time and effort to do so.

Well, maybe you didn't shut them down immediately. I would participate to the best of my abilities if you would shut me down with your arrogant attitude.

...

I am more than willing to help as I do in a lot of other projects, but I can always only contribute to the extent of my abilities (and the time I have).

As can I. Yet for some reason, that excuse is valid for you, but you don't think it's valid for me.

i.e. You don't have the time or inclination to work through the issue you opened, and you think that's fine. But if I don't do that work and instead close the issue, then I'm a bad person.

Yes. You have closed the issue instead of giving me an opportunity to make myself clearer. So you don't have the time or inclination to work through the issue I have opened, trying to understand the issue and how 'extremely confusing' it all is. And how that is even much harder for people who haven't dealt with openssl for many years and understand the basic concepts of it all.

...

You are disappointed that there is a large group of people who have suggestions how to improve something or who find issues in how things are, but who are not able to contribute significantly...

At the minimum, I expect contributions to be something more than "I did a bunch of stuff. It didn't work the way I expected. You need to fix it".

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. But I only got to that point but not really following what is clearly mentioned in the comments. I got to that point by briefly checking the source code to get some idea where those parameters might be used and how they map down to the common openssl configurations for tls servers and client verification. I got to that point because I think I understood the mixed used of some of those parameters for tls servers and client verification from that, thus separating it by a certain way of configuration, from experience with openssl. So it works and I hope it really only works the way I expect it. But to clarify the documentation is difficult if you don't have a deeper understanding of where everything is used exactly. It'll takes me hours to figure that out, what a developer just knows...

...

You can either pick that up, show some interest and start a discussion which could well go deeper, or you can simply be disappointed and tell people that they "have time and energy to criticize, but none to contribute", expecting them (between the lines) to provides fully finished code patches which you can review.

We both know hat isn't what I said. I've asked you for documentation updates, or for a clearer description of the problem. Oh. Yes. That's very much what you basically said, whether you call it "documentation updates" now. If you asking for a PR that's what you do.

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. The problem in the end is, that you don't even acknowledge that the documentation is misleading, confusing and sometimes simply wrong. I know it's easier to find out that it's wrong, and harder to write it correctly, which requires an understanding of it. But that doesn't come from a guess deducted from a misleading documentation... I cannot write documentation on what "ca_file" and "ca_dir" does exactly when I don't know what it does exactly and where it's used. It may be used for tls server or client verification or both, and maybe only ca_file if it's defined or maybe both, or maybe only one in certain situations. That is the problem. How much clearer do you need it? I can guess and write an update, although I hardly know if it's so much more accurate...

If you need to lie in order to "win" an argument, that's a lot more problematic than my "negative" attitude of asking you to a little bit of work.

I don't have to win this argument. I know by know that you won't change and you won't bother even trying to understand. You always win the argument because you have the power and if people don't do what you tell them to do then you can just simply shut them down.

...

I would love to participate and contribute

Apparently not.

I do. But you really working very hard to make me change my mind. You must really think, I have nothing better to do then write lengthy replies trying to explain my point, even though I am pretty sure that I won't get through to you... But I suppose it is what it is. If you don't immediately understand an issue it's obviously the fault of the other person. I mean in the github issue above I wasn't the only one who finds it confusing... And from many mails here on this list I think it also should be clear that it's confusing. Anyways, I guess I spent enough time on this. I have explained originally to someone else how I understand how it works and how it needs to be configured. You don't like that either, but have to put in your standard "Patches are welcome", which of course is obviously more then rhetoric by you, because you know that it's pretty unlikely that the average person would quickly rewrite the use of certificates and submit a patch... I have explained to someone else the trusted and untrusted certificates. If that's a problem for you or doesn't fit your standards, well, no need to repeat your "patches are welcome"... Over and out, Gerald

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

On 24.01.24 21:56, Alan DeKok wrote:

On Jan 24, 2024, at 2:16 PM, Gerald Vogt <vogt@spamcop.net> wrote:

...

I have explained several points in my second message in the ticket.

Which I had responded to, but OK...

Only to a little part.

...

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

Now, that is incorrect. The instructions tell me to put the server chain cas and all cas required for client authentication into the same file for ca_file. Many server CAs issues certs with client and server authentication set. Let's encrypt does so. The certificate for the freeradius.org web server has it. And I guess it's pretty common nowadays because many web servers also have outgoing backend connection for which they can simply use the same certificate. Or our mail servers all have certificates with server and client authentication set and use them for client authentication when forwarding mails throughout the internal relay network. It's not my CA and the server certs issued have it both. It's useful and common practice. With our old CA we had the option to specify which purposes should go into the server cert, but both client and server authentication was also an option. With our new CA it always issues server certs with client and server authentication purpose set in the x509v3 extensions.

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

That is correct. But your assumption that a CA should issue server certs witih client authentication included is wrong.

...

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.

However, your assumption is invalid that it doesn't help.

...

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

It includes the intermediate CAs.

It does not say so in the text "Trusted Root CA list". I think there is a clear definition of what a root ca is and an intermediate ca is not a root ca. I am just reading what is written in the comments and I would assume people will do what is written (o.k. many don't but that's another story).

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

Yes, I know. But again: you don't have to explain to me how openssl works. I am just following the instructions from the comments. I have seen my share of half baked ssl servers which do all kind of weird stuff. Thus for a start, I look at the text and what it says, even though I can guess what's really behind and can assume that ca_file is what is passed to -CAfile in the openssl tools and thus can and should include intermediates as well.

...

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.

I can try and see and I did and that's why I am not using it the way the comments tell me to. And again: to really submit a meaningful PR I need to understand what it really does. Of course, I can start intensive testing to find out what it does (at the places I can think of and that I am using). I can also search through the source code to find possible other uses I haven't thought of or that I don't use. My general presumption is that whoever wrote 'Trusted Root CA list' had a reason to write "Root CA list" and not "CA list" and why it was specifically attributed as "trusted" (following the distinction of the -trusted and -untrusted options of openssl). So yes, I can spend a lot of time to find out and make the best guess I can do and submit a PR for something which probably someone who knows the code inside and out can clarify in a minute...

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

Really "figuring things out" means, however, to find ALL places where this parameter is used in the source code, understanding what is happening at all these places and the consequences.

...

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

It is still what's written there and which people who follow the instructions should do. I mean, you are the one you repeatedly tells people to read the welcome message and do what it says...

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 text in the comments does not. It clearly says otherwise, even if says 'should'.

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

The comments suggest contradictory and thus confusing best practices.

...

# # 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?

The ca_file was for the "Trusted Root CA list" according to the comment. It was specifically for client authentication and for the server chain. ca_path is simply mentioned as "Directory where multiple CAs are stored", nothing else. It sounds like just another directory where you can store CAs. It's not mentioned as "trusted root ca directory" or similar. You may know that ca_file and ca_path are internally interchangeably and in the same places. But as I wrote before: I have seen my share of bad ssl servers which have named configuration options in their own names and sometimes using one in the one place and the other in other place. Thus, just reading the text in the comments ca_file sounds very important and special and ca_path is, well, just another directory which will be used for whatnot. And things like this can confuse people and cause problems and make them ask those "dumb" questions on the list...

...

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 comments don't.

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.

Unclear, ambiguous comments or documentation is an issue. It makes people think at least if this difference is for a reason or not and which way may be the right way to do it.

...

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

Nope. Not with any security related service. "it works" does not mean "correctly configured". I kind of makes me understand why you keep mentioning the "magic" in openssl. People don't spend the time to understand it and just guess and try and it works and they are happy. Of course, they never fully test it for all aspects what what should be accepted and what not. The next project comes and picks up the code and does in the same way. It works. It's correctly configured. But who knows...

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

You never stop that, don't you? You really want to get rid of me.

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

But do you see that it doesn't help if you block off people who are trying to understand the details in order to be able to contribute? You don't want to understand the problem. You know how it works. There is no problem.

...

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.

Well, just take the statements I made and look at the statements to which you responded. Their is a discrepancy.

...

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 comments say I "should" do otherwise. And everyone who is not sitting every day over the radius configuration will look at whats written in the comments. You know how it works. You don't have to read the comments. But it is actually possible to describe those options clearly. For instance, if I read the ssl.conf for mod_ssl of httpd: # Server Certificate Chain: # Point SSLCertificateChainFile at a file containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for the server certificate. Alternatively # the referenced file can be the same as SSLCertificateFile # when the CA certificates are directly appended to the server # certificate for convenience. #SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt # Certificate Authority (CA): # Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one # huge file containing all of them (file must be PEM encoded) #SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

...

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.

I don't know about that, but adding confusing comments in the configuration files as guidance doesn't help. I have never had any problems setting up a httpd tls server. No hell. Nothing weird. It's clear and straight forward. Even with client authentication set up...

...

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.

I write long emails explaining it in length and you say I "refused"?? Seriously?? You are really not reading my mails. You are really not even starting to try to understand what I write. You want me to explain, I do explain, but you don't accept my explanation but instead say I refused to explain. You just don't want my explanation. That is just arrogant.

That's not an approach intended to make friends.

Well, right back at you.

...

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.

Yes. I did. It works. Nothing unclear about it. The TLS configuration works as expected. No "magic" or "hell".

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

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

You are taking that out of context. I didn't say that the nginx documentation is good. My statement above was in the reply to the "openssl" magic you claim. I haven't seen any "magic" or "hell" in either case. Nothing surprising or out of the ordinary.

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.

No, you are just taking a statement regarding something else out of context.

...

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.

I am sorry, if my feedback is more complicated and thus not good enough for you. Though I don't know how to make it clearer when two statements kind of contradict each other.

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.

Well, hundreds of lines of explanation are nothing worth for your and instead you tell me I "refused" an explanation. I understand. You don't want my feedback. You don't even want to know my feedback.

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!"

Again, arrogance: obviously my previous contributions to others is obviously nothing worth in your eyes. I guess a real contribution is only one which ends up in a PR?

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.

O.K. Thanks for the clarification. Any worthy contribution in your eyes is only a patch. You made it absolutely clear by now, it verbatim statements, that you don't want my contribution in any kind. Who am I to dare I might post something on this list to help someone else?? I am very sorry to have disturbed your reign on what is worthy of your attention and considered a worthy contribution. You must really like to piss people off... g