By the way, that's a good case that shows why it really pays to use new-style config for more complex things.
If new style would have been used, rsyslog would have emitted an error message. Just to mention this. Glad it worked out. Rainer El jue, 17 ago 2023 a las 12:29, Roman Möller via rsyslog (<rsyslog@lists.adiscon.com>) escribió: > > Hi all, > just wanted to give you a final update on the case. > There was no problem with rsyslog, it was a configuration error on my end. > > The reason for the observed behavior was that there was another *.conf file > from a different user of the system stored in /etc/rsyslog.d/ with a > different value set for DefaultNetstreamDriverCAFile. > This value pointed to another ca bundle in a different location on the system. > This to me unbeknown config file overruled my config and therefore showed the > "Acceptable client certificate CA names" from the other ca bundle. > > After I resolved the configuration conflict, everything worked as expected. > > Case closed and thanks for the help! 😊 > > Kind regards, > Roman Möller (He/His) > > > > > > > -----Ursprüngliche Nachricht----- > Von: Andre Lorbach <alorb...@adiscon.com> > Gesendet: Freitag, 4. August 2023 12:07 > An: rsyslog-users <rsyslog@lists.adiscon.com> > Cc: Roman Möller <roman.moel...@eviden.com> > Betreff: RE: [rsyslog] Support for multiple certificate chains (TLS) > > Caution: External email. Do not open attachments or click links, unless this > email comes from a known sender and you know the content is safe. > > If you have a test machine you can use our own daily build rpm packages for > testing. > We have daily build RHEL 7,8 and 9 packages available here: > # for CentOS 7,8,9 > http://rpms.adiscon.com/v8-stable-daily/rsyslog-daily.repo > # for RHEL 7,8,9 > http://rpms.adiscon.com/v8-stable-daily/rsyslog-daily-rhel.repo > > You may need to use --disableplugin=priorities when you want to install > rsyslog from our repo depending on your RHEL / CentOS Version. > > We also have scheduled stable packages here only updated after release: > # for CentOS 7,8,9 > http://rpms.adiscon.com/v8-stable/rsyslog.repo > # for RHEL 7,8,9 > http://rpms.adiscon.com/v8-stable/rsyslog-rhel.repo > > Best regards, > Andre Lorbach > -- > Adiscon GmbH > Mozartstr. 21 > 97950 Großrinderfeld, Germany > Ph. +49-9349-9298530 > Geschäftsführer/President: Rainer Gerhards Reg.-Gericht Mannheim, HRB > 560610 > Ust.-IDNr.: DE 81 22 04 622 > Web: www.adiscon.com - Mail: i...@adiscon.com > > Informations regarding your data privacy policy can be found here: > https://www.adiscon.com/data-privacy-policy/ > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient or have received this e-mail in error please > notify the sender immediately and delete this e-mail. Any unauthorized > copying, disclosure or distribution of the material in this e-mail is > strictly forbidden. > > > -----Original Message----- > > From: rsyslog <rsyslog-boun...@lists.adiscon.com> On Behalf Of Roman > > Möller via rsyslog > > Sent: Donnerstag, 3. August 2023 11:45 > > To: rsyslog-users <rsyslog@lists.adiscon.com> > > Cc: Roman Möller <roman.moel...@eviden.com> > > Subject: Re: [rsyslog] Support for multiple certificate chains (TLS) > > > > I've tested a little bit further and perhaps found something interesting. > > In general I use this config: > > global( > > DefaultNetstreamDriver="gtls" > > DefaultNetstreamDriverCAFile="/etc/rsyslog.d/ca_mixed.pem" > > DefaultNetstreamDriverCertFile="/etc/rsyslog.d/cert.pem" > > DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/key.pem" > > ) > > module( > > load="imtcp" > > StreamDriver.Name="gtls" > > StreamDriver.Mode="1" > > StreamDriver.Authmode="anon" > > ) > > input( > > type="imtcp" > > port="6514" > > ) > > > > When I do a testconnection with "openssl s_client -connect localhost:6514" > > on the system with rsyslogd 8.2102.0-13.el8 (aka 2021.02) running I > > get the following output: > > [...] > > Acceptable client certificate CA names C = DE, O = Democompany Inc., > > CN = Democompany Inc. - Intermediate CA-1 C = DE, O = Democompany > > Inc., CN = Democompany Inc. - Root-CA [...] > > > > When I do a testconnection with " openssl s_client -connect > > localhost:6514" > > on the system with rsyslogd 8.2102.0-10.el8 (aka 2021.02) running I > > get the following output: > > [...] > > Acceptable client certificate CA names CN = CA1 CN = CA2 C = DE, O = > > Democompany Inc., CN = Democompany Inc. - Intermediate CA-1 C = DE, O > > = Democompany Inc., CN = Democompany Inc. - Root-CA C = US, O = > > Amazon, CN = Amazon Root CA 4 [...] > > > > ca_mixed.pem has the same content in both tests. So it seems that > > something is broken in the newer version (at least in the Red Hat > > version) > > > > On rsyslogd 8.2102.0-13.el8 (aka 2021.02) when I use an empty > > ca_mixed.pem it shows in " Acceptable client certificate CA names" > > certificates > > which seem to come from the own rsyslog certificate > > "/etc/rsyslog.d/cert.pem" > > > > Can you see this behavior in the vanilla rsyslog too? > > > > Kind regards, > > Roman Möller (He/His) > > > > > > > > > > > > > > -----Ursprüngliche Nachricht----- > > Von: rsyslog <rsyslog-boun...@lists.adiscon.com> Im Auftrag von Rainer > > Gerhards via rsyslog > > Gesendet: Mittwoch, 2. August 2023 10:48 > > An: rsyslog-users <rsyslog@lists.adiscon.com> > > Cc: Rainer Gerhards <rgerha...@hq.adiscon.com> > > Betreff: Re: [rsyslog] Support for multiple certificate chains (TLS) > > > > Caution: External email. Do not open attachments or click links, > > unless this email comes from a known sender and you know the content > > is safe. > > > > Thanks - the RELP info is a good pointer! > > > > Rainer > > > > El mié, 2 ago 2023 a las 10:27, Mariusz Kruk via rsyslog > > (<rsyslog@lists.adiscon.com>) escribió: > > > > > > Sorry, I'm just a simple admin. I wouldn't touch the TLS-related > > > programming with a ten-foot pole. Tried it once, long time ago, got > > > my hair a bit more grayish and ran away screaming ;-) > > > > > > But, to make things more interesting as far as I remember loading > > > certificate chains (for RELP) worked relatively well with gnutls way > > > before it did with openssl. > > > > > > MK > > > > > > On 2.08.2023 10:21, Rainer Gerhards wrote: > > > > disclaimer: I did not read the full message > > > > BUT: I think you are both right. > > > > > > > > It actually should work in the way Mariusz describes, but for many > > > > software products it actually does work like Andre describes (I > > > > think even some web server). > > > > > > > > Not sure if it is a lib limitation or something we need to enable > > > > inside the lib. > > > > > > > > A good indication that there seems to be a general problem is that > > > > the multi-ca patch came from RH, quoting intermediate CAs IIRC. > > > > > > > > Andre: can you craft a test with interim certs and let's see what > > > > happens? > > > > Mariusz: do you happen to know special lib settings out of your > > > > head (don't dig deep, we can research this as well) > > > > > > > > Rainer > > > > > > > > El mié, 2 ago 2023 a las 10:17, Mariusz Kruk via rsyslog > > > > (<rsyslog@lists.adiscon.com>) escribió: > > > >> No. It's not how it works. > > > >> > > > >> If a client A's cerificate was issued by intermediate CA B which > > > >> was issued a signing cert by RootCA C, the server only has to > > > >> trust B to "directly" authenticate the client. (and this was for > > > >> a long time the only supported option for RELP). In such case the > > > >> server nows the cert of B and the client only presents its own cert A. > > > >> Neither party needs to show the cert of the RootCA since it's not > > > >> needed for the trust relation to work. The problem (again - which > > > >> I had for a long time with RELP > > > >> connectivity) was when you could not specify multiple trusted CAs > > > >> and you had clients using certificates from different CAs (like a > > > >> common rootCA but two separate intermediate CAs in one organization). > > > >> > > > >> Normally the server should trust the RootCA C and the client > > > >> should present the cert along with the certification chain. So > > > >> client A should show cert A and cert B to the server. The server > > > >> would then verify that A was signed by B and B was signed by C > > > >> which it knows and > > trusts. > > > >> That's the way it normally works. And that's the way it's been > > > >> working finally since... 2021? with imrelp/omrelp. But with those > > > >> modules you can specify the certs explicitly (since 2020? Before > > > >> that you could only use the default netdriver settings). The only > > > >> limitation as far as I remember (maybe it changed in recent > > > >> versions) was that you couldn't specify multiple trusted certs so > > > >> you could trust a single RootCA and accept certificates from > > > >> multiple intermediate CAs this way but couldn't accept > > > >> certificates from > > multiple CAs signed by multiple different RootCAs. > > > >> > > > >> Maybe with imtcp it works differently. Normally TLS-backed > > > >> authentication should work this way. > > > >> > > > >> MK > > > >> > > > >> On 2.08.2023 09:47, Andre Lorbach wrote: > > > >>> Ok to be honest I have not worked with intermediate CA generated > > > >>> certificates yet, so I can only stick to the documentation I > > > >>> found. As far as I understand, the server needs to know the root > > > >>> and intermediate CA certificate, if he shall be able to verify > > > >>> the client certificate. > > > >>> > > > >>> If the client shall present the intermediateCA to the server, It > > > >>> needs to have support for this. I remembered that there was a > > > >>> similar issue last year which was fixed by this PR: > > > >>> https://github.com/rsyslog/rsyslog/pull/4889 > > > >>> > > > >>> A new setting NetstreamDriverCAExtraFiles was added with this PR > > > >>> to address issues like this. However, you will require at least > > > >>> rsyslog > > v8.2210.0. > > > >>> > > > >>> Best regards, > > > >>> Andre Lorbach > > > >>> -- > > > >>> Adiscon GmbH > > > >>> Mozartstr. 21 > > > >>> 97950 Großrinderfeld, Germany > > > >>> Ph. +49-9349-9298530 > > > >>> Geschäftsführer/President: Rainer Gerhards Reg.-Gericht > > > >>> Mannheim, HRB > > > >>> 560610 > > > >>> Ust.-IDNr.: DE 81 22 04 622 > > > >>> Web: www.adiscon.com - Mail: i...@adiscon.com > > > >>> > > > >>> Informations regarding your data privacy policy can be found here: > > > >>> https://www.adiscon.com/data-privacy-policy/ > > > >>> > > > >>> This e-mail may contain confidential and/or privileged > > > >>> information. If you are not the intended recipient or have > > > >>> received this e-mail in error please notify the sender > > > >>> immediately and delete this e-mail. Any unauthorized copying, > > > >>> disclosure or distribution of the material in this e-mail is strictly > > > >>> forbidden. > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: rsyslog <rsyslog-boun...@lists.adiscon.com> On Behalf Of > > > >>>> Mariusz Kruk via rsyslog > > > >>>> Sent: Mittwoch, 2. August 2023 08:45 > > > >>>> To: rsyslog@lists.adiscon.com > > > >>>> Cc: Mariusz Kruk <k...@epsilon.eu.org> > > > >>>> Subject: Re: [rsyslog] Support for multiple certificate chains > > > >>>> (TLS) > > > >>>> > > > >>>> Wait a second. > > > >>>> > > > >>>> Firstly, and most importantly, the whole idea of multiple CA > > > >>>> levels is that if a subject A presents a cert issued by CA B > > > >>>> which in turn was issued a signing cert by RootCA C it should > > > >>>> be enough for the other end to just trust the RootCA C. > > > >>>> > > > >>>> So in the OP's situation it should be enough to have the RootCA > > > >>>> as a trusted cert and the sending parties should present proper > > > >>>> certificate chains including the subject cert and the > > > >>>> intermediate CA cert. > > > >>>> > > > >>>> That's how it works (currently; it didn't for quite some time > > > >>>> which had been a source of huge grief for me) with imrelp/omrelp. > > > >>>> I'm not sure about imtcp with TLS simply because I don't use it. > > > >>>> > > > >>>> MK > > > >>>> > > > >>>> On 2.08.2023 08:39, Andre Lorbach via rsyslog wrote: > > > >>>>> Dear Roman, > > > >>>>> > > > >>>>> technically the GnuTLS and OpenSSL API do support loading > > > >>>>> multiple CA Certificates in one file. I have not tested this, > > > >>>>> but you can combine all 3 root CA certificates into one file, > > > >>>>> it should > > work. > > > >>>>> > > > >>>>> For example: > > > >>>>> cat intermediateCA_1.crt intermediateCA_2.crt rootCA.crt > > > >>>>> > rootCA_and_all_intermediateCA.pem > > > >>>>> > > > >>>>> $DefaultNetstreamDriver gtls > > > >>>>> $DefaultNetstreamDriverCAFile > > > >>>>> /etc/pki/rsyslog/rootCA_and_all_intermediateCA.pem > > > >>>>> $DefaultNetstreamDriverCertFile > > > >>>>> /etc/pki/rsyslog/rsyslogServer.crt > > > >>>>> $DefaultNetstreamDriverKeyFile > > > >>>>> /etc/pki/rsyslog/rsyslogServer.key > > > >>>>> > > > >>>>> Best regards, > > > >>>>> Andre Lorbach > > > >>>>> -- > > > >>>>> Adiscon GmbH > > > >>>>> Mozartstr. 21 > > > >>>>> 97950 Großrinderfeld, Germany > > > >>>>> Ph. +49-9349-9298530 > > > >>>>> Geschäftsführer/President: Rainer Gerhards Reg.-Gericht > > > >>>>> Mannheim, HRB > > > >>>>> 560610 > > > >>>>> Ust.-IDNr.: DE 81 22 04 622 > > > >>>>> Web: www.adiscon.com - Mail: i...@adiscon.com > > > >>>>> > > > >>>>> Informations regarding your data privacy policy can be found here: > > > >>>>> https://www.adiscon.com/data-privacy-policy/ > > > >>>>> > > > >>>>> This e-mail may contain confidential and/or privileged > > > >>>>> information. If you are not the intended recipient or have > > > >>>>> received this e-mail in error please notify the sender > > > >>>>> immediately and delete this e-mail. Any unauthorized copying, > > > >>>>> disclosure or distribution of the material in this e-mail is > > > >>>>> strictly > > forbidden. > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: rsyslog <rsyslog-boun...@lists.adiscon.com> On Behalf > > > >>>>>> Of Roman Möller via rsyslog > > > >>>>>> Sent: Montag, 31. Juli 2023 18:18 > > > >>>>>> To: rsyslog@lists.adiscon.com > > > >>>>>> Cc: Roman Möller <roman.moel...@eviden.com> > > > >>>>>> Subject: [rsyslog] Support for multiple certificate chains > > > >>>>>> (TLS) > > > >>>>>> > > > >>>>>> Hello subscribers, > > > >>>>>> we are using rsyslog with TLS to collect logs transport > > > >>>>>> encrypted from different logsources. > > > >>>>>> The used certificates are generated by our company CA for the > > > >>>>>> rsyslog server but also for the logsources. > > > >>>>>> > > > >>>>>> I have used these setting until now (filename gives hint > > > >>>>>> about > > > >>>>>> content): > > > >>>>>> $DefaultNetstreamDriver gtls > > > >>>>>> $DefaultNetstreamDriverCAFile > > > >>>>>> /etc/pki/rsyslog/rootCA_and_intermediateCA-1.pem > > > >>>>>> $DefaultNetstreamDriverCertFile > > > >>>>>> /etc/pki/rsyslog/rsyslogServer_and_ > > > >>>>>> intermediateCA-1.crt $DefaultNetstreamDriverKeyFile > > > >>>>>> /etc/pki/rsyslog/rsyslogServer.key > > > >>>>>> > > > >>>>>> And the reception of logs worked pretty well so far. > > > >>>>>> > > > >>>>>> Now we have a new intermediate CA and the certificate chains > > > >>>>>> look like > > > >>>>>> this: > > > >>>>>> +------------+ > > > >>>>>> | Root-CA | > > > >>>>>> +------------+ > > > >>>>>> | > > > >>>>>> +--------------------+--------------------------+ > > > >>>>>> | > > > >>>>>> | > > > >>>>>> v > > > >>>>>> v > > > >>>>>> +--------------------------+ > > > >>>>>> +--------------------------+ > > > >>>>>> | Intermediate CA-1 | | Intermediate CA-2 > > > >>>>>> | > > > >>>>>> +--------------------------+ > > > >>>>>> +--------------------------+ > > > >>>>>> | > > > >>>>>> | > > > >>>>>> v > > > >>>>>> v > > > >>>>>> +-----------------------------------+ > > > >>>>>> +-----------------------------------+ +---------------------- > > > >>>>>> +-----------------------------------+ +-- > > > >>>>>> +-----------------------------------+ +------ > > > >>>>>> +-----------------------------------+ +--- > > > >>>>>> +-----------------------------------+ + > > > >>>>>> | Generated the certificate | | Generated certificates > > > >>>>>> | > > > >>>>>> | for the rsyslog Server | | for yet other > > > >>>>>> logsources > > > >>>>>> | > > > >>>>>> | but also for other | > > > >>>>>> +---------------------------------+ > > > >>>>>> | logsources | > > > >>>>>> +-----------------------------------+ > > > >>>>>> > > > >>>>>> Our rsyslog Server is not able to accept syslog-TLS encrypted > > > >>>>>> traffic from logsources which have a certificate from > > > >>>>>> Intermediate > > CA-2. > > > >>>>>> A test with openssl s_client -connect localhost:6514 shows > > > >>>>>> that the system only accepts certificates which originate > > > >>>>>> from Intermediate > > > >>>>>> CA-1 > > > >>>>>> > > > >>>>>> We are using rsyslogd 8.2102.0-10.el8 (aka 2021.02) at the > > moment. > > > >>>>>> > > > >>>>>> Is it somehow possible to configure the acceptance of > > > >>>>>> certificates from both Intermediate CAs or is this simply not > > > >>>>>> possible with one instance of rsyslog? > > > >>>>>> > > > >>>>>> Kind regards and thanks in advance, Roman Möller (He/His) > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> _______________________________________________ > > > >>>>>> rsyslog mailing list > > > >>>>>> https://lists.adiscon.net/mailman/listinfo/rsyslog > > > >>>>>> http://www.rsyslog.com/professional-services/ > > > >>>>>> What's up with rsyslog? Follow https://twitter.com/rgerhards > > > >>>>>> NOTE > > WELL: > > > >>>>>> This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > > > >>>>>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT > > POST > > > >>>>>> if you DON'T LIKE THAT. > > > >>>>> _______________________________________________ > > > >>>>> rsyslog mailing list > > > >>>>> https://lists.adiscon.net/mailman/listinfo/rsyslog > > > >>>>> http://www.rsyslog.com/professional-services/ > > > >>>>> What's up with rsyslog? Follow https://twitter.com/rgerhards > > > >>>>> NOTE > > > >>>>> WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a > > > >>>>> myriad of sites > > > >>>> beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > > > >>>> DON'T LIKE THAT. > > > >>>> _______________________________________________ > > > >>>> rsyslog mailing list > > > >>>> https://lists.adiscon.net/mailman/listinfo/rsyslog > > > >>>> http://www.rsyslog.com/professional-services/ > > > >>>> What's up with rsyslog? Follow https://twitter.com/rgerhards > > > >>>> NOTE > > WELL: > > > >>>> This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > > > >>>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST > > > >>>> if you DON'T LIKE THAT. > > > >> _______________________________________________ > > > >> rsyslog mailing list > > > >> https://lists.adiscon.net/mailman/listinfo/rsyslog > > > >> http://www.rsyslog.com/professional-services/ > > > >> What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE > > > >> WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a > > > >> myriad of > > sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > > DON'T LIKE THAT. > > > _______________________________________________ > > > rsyslog mailing list > > > https://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com/professional-services/ > > > What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE > > > WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > > > of sites > > beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > > LIKE THAT. > > _______________________________________________ > > rsyslog mailing list > > https://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com/professional-services/ > > What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: > > This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites > > beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > > LIKE THAT. > > _______________________________________________ > > rsyslog mailing list > > https://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com/professional-services/ > > What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: > > This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites > > beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > > LIKE THAT. > _______________________________________________ > rsyslog mailing list > https://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of > sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T > LIKE THAT. _______________________________________________ rsyslog mailing list https://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
