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.
