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-bounces@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 <rgerhards@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: info@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-bounces@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 <kruk@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: info@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-bounces@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.moeller@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.