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.
