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.
