Mailing List Archive

TLS is killing me ;-)
I'm having a distributed setup using a central "collector" and many
"small" rsyslog instances receiving events on remote locations.

Those small sites send events "upstream" using TLS-protected RELP with
mutual cert-based authentication.

Problem is, I used to have trustchain working like that: "CA1 -> CA2 ->
CA3 -> client cert". And it worked for many clients (around two dozens, I
believe). I had "CA1 -> CA2 -> CA3" provided as trust chain on both side
of the connection (both in imrelp and omrelp configuration as tls.CACert
parameter) and just gave plain client cert as tls.MyCert.

Worked great until now because I sudenly created CSR to the CA and got in
response a cert with a different chain - "CA2 -> CA4 -> client cert".
Obviously when I configure my client with this cert, it's not valid
becaues the CA4 cert cannot be authenticated by the other end.

Do I have any other option than to simply reconfigure all ends to use CA1
as CACert and append CAs to client certs to make them chained certs? Of
course since I have already many clients deployed I'd really like to avoid
that but if there's no other choice.

I'm using:

# rpm -q rsyslog

rsyslog-8.2001.0-3.el7.x86_64

TIA for any words of advice.



_______________________________________________
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.
Re: TLS is killing me ;-) [ In reply to ]
just as a FYI, 8.2010 includeed some pretty significant TLS improvements. I
don't think they are related to what you are fighting, but I think you will want
to upgrade (at least on the receiver)

David Lang

On Tue, 22 Dec 2020, Mariusz Kruk via rsyslog wrote:

> Date: Tue, 22 Dec 2020 12:45:03 +0100 (CET)
> From: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
> To: rsyslog@lists.adiscon.com
> Cc: Mariusz Kruk <mkr@safecomp.com>
> Subject: [rsyslog] TLS is killing me ;-)
>
> I'm having a distributed setup using a central "collector" and many
> "small" rsyslog instances receiving events on remote locations.
>
> Those small sites send events "upstream" using TLS-protected RELP with
> mutual cert-based authentication.
>
> Problem is, I used to have trustchain working like that: "CA1 -> CA2 ->
> CA3 -> client cert". And it worked for many clients (around two dozens, I
> believe). I had "CA1 -> CA2 -> CA3" provided as trust chain on both side
> of the connection (both in imrelp and omrelp configuration as tls.CACert
> parameter) and just gave plain client cert as tls.MyCert.
>
> Worked great until now because I sudenly created CSR to the CA and got in
> response a cert with a different chain - "CA2 -> CA4 -> client cert".
> Obviously when I configure my client with this cert, it's not valid
> becaues the CA4 cert cannot be authenticated by the other end.
>
> Do I have any other option than to simply reconfigure all ends to use CA1
> as CACert and append CAs to client certs to make them chained certs? Of
> course since I have already many clients deployed I'd really like to avoid
> that but if there's no other choice.
>
> I'm using:
>
> # rpm -q rsyslog
>
> rsyslog-8.2001.0-3.el7.x86_64
>
> TIA for any words of advice.
>
>
>
> _______________________________________________
> 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.
Re: TLS is killing me ;-) [ In reply to ]
Thanks for the heads-up. It's probably due some time in the future but it'll
require some good testing first. I won't roll-out into production lightly
since we're having something like 500GB of logs daily ????
After some thinking I realized one more thing. I can of course "go upstream"
with the CA's and try to authenticate with chained certs and keep only root
CA, not the whole trustchain on the receiver but still there'll come a day
when rootCA cert expires and I'll have to switch to a new one. So eventually
I will have to have a possibility to have at least two different CA's to
verify clients' certs with.
Is it at all possible?



-----Original Message-----
From: David Lang <david@lang.hm>
Sent: Tuesday, December 22, 2020 6:10 PM
To: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
Cc: Mariusz Kruk <mkr@safecomp.com>
Subject: Re: [rsyslog] TLS is killing me ;-)

just as a FYI, 8.2010 includeed some pretty significant TLS improvements. I
don't think they are related to what you are fighting, but I think you will
want to upgrade (at least on the receiver)

David Lang

On Tue, 22 Dec 2020, Mariusz Kruk via rsyslog wrote:

> Date: Tue, 22 Dec 2020 12:45:03 +0100 (CET)
> From: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
> To: rsyslog@lists.adiscon.com
> Cc: Mariusz Kruk <mkr@safecomp.com>
> Subject: [rsyslog] TLS is killing me ;-)
>
> I'm having a distributed setup using a central "collector" and many
> "small" rsyslog instances receiving events on remote locations.
>
> Those small sites send events "upstream" using TLS-protected RELP with
> mutual cert-based authentication.
>
> Problem is, I used to have trustchain working like that: "CA1 -> CA2
> ->
> CA3 -> client cert". And it worked for many clients (around two
> dozens, I believe). I had "CA1 -> CA2 -> CA3" provided as trust chain
> on both side of the connection (both in imrelp and omrelp
> configuration as tls.CACert
> parameter) and just gave plain client cert as tls.MyCert.
>
> Worked great until now because I sudenly created CSR to the CA and got
> in response a cert with a different chain - "CA2 -> CA4 -> client cert".
> Obviously when I configure my client with this cert, it's not valid
> becaues the CA4 cert cannot be authenticated by the other end.
>
> Do I have any other option than to simply reconfigure all ends to use
> CA1 as CACert and append CAs to client certs to make them chained
> certs? Of course since I have already many clients deployed I'd really
> like to avoid that but if there's no other choice.
>
> I'm using:
>
> # rpm -q rsyslog
>
> rsyslog-8.2001.0-3.el7.x86_64
>
> TIA for any words of advice.
>
>
>
> _______________________________________________
> 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.
Re: TLS is killing me ;-) [ In reply to ]
No, currently rsyslog only supports using a single cert across everything

There are enhancement requests in to expand this, but I don't think any of them
cover the problem of accepting multiple certs to facilitate a transition from
one cert to another on the other end.

David Lang

On Wed, 23 Dec 2020, Mariusz Kruk via rsyslog wrote:

> Date: Wed, 23 Dec 2020 08:21:27 +0100 (CET)
> From: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
> To: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
> Cc: Mariusz Kruk <mkr@safecomp.com>
> Subject: Re: [rsyslog] TLS is killing me ;-)
>
> Thanks for the heads-up. It's probably due some time in the future but it'll
> require some good testing first. I won't roll-out into production lightly
> since we're having something like 500GB of logs daily ????
> After some thinking I realized one more thing. I can of course "go upstream"
> with the CA's and try to authenticate with chained certs and keep only root
> CA, not the whole trustchain on the receiver but still there'll come a day
> when rootCA cert expires and I'll have to switch to a new one. So eventually
> I will have to have a possibility to have at least two different CA's to
> verify clients' certs with.
> Is it at all possible?
>
>
>
> -----Original Message-----
> From: David Lang <david@lang.hm>
> Sent: Tuesday, December 22, 2020 6:10 PM
> To: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
> Cc: Mariusz Kruk <mkr@safecomp.com>
> Subject: Re: [rsyslog] TLS is killing me ;-)
>
> just as a FYI, 8.2010 includeed some pretty significant TLS improvements. I
> don't think they are related to what you are fighting, but I think you will
> want to upgrade (at least on the receiver)
>
> David Lang
>
> On Tue, 22 Dec 2020, Mariusz Kruk via rsyslog wrote:
>
>> Date: Tue, 22 Dec 2020 12:45:03 +0100 (CET)
>> From: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
>> To: rsyslog@lists.adiscon.com
>> Cc: Mariusz Kruk <mkr@safecomp.com>
>> Subject: [rsyslog] TLS is killing me ;-)
>>
>> I'm having a distributed setup using a central "collector" and many
>> "small" rsyslog instances receiving events on remote locations.
>>
>> Those small sites send events "upstream" using TLS-protected RELP with
>> mutual cert-based authentication.
>>
>> Problem is, I used to have trustchain working like that: "CA1 -> CA2
>> ->
>> CA3 -> client cert". And it worked for many clients (around two
>> dozens, I believe). I had "CA1 -> CA2 -> CA3" provided as trust chain
>> on both side of the connection (both in imrelp and omrelp
>> configuration as tls.CACert
>> parameter) and just gave plain client cert as tls.MyCert.
>>
>> Worked great until now because I sudenly created CSR to the CA and got
>> in response a cert with a different chain - "CA2 -> CA4 -> client cert".
>> Obviously when I configure my client with this cert, it's not valid
>> becaues the CA4 cert cannot be authenticated by the other end.
>>
>> Do I have any other option than to simply reconfigure all ends to use
>> CA1 as CACert and append CAs to client certs to make them chained
>> certs? Of course since I have already many clients deployed I'd really
>> like to avoid that but if there's no other choice.
>>
>> I'm using:
>>
>> # rpm -q rsyslog
>>
>> rsyslog-8.2001.0-3.el7.x86_64
>>
>> TIA for any words of advice.
>>
>>
>>
>> _______________________________________________
>> 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.
Re: TLS is killing me ;-) [ In reply to ]
But as far as I can see in the docs (haven't tested it yet though), omrelp
as well as imrelp support providing tls options per input/output instance
isn't that right?
So I could just set up two different inputs with different CA's on different
ports (and possibly for the sake of not touching the network rules, migrate
from one CA setup to the other using local REDIRECT target in iptables).
Will have to try this idea first thing next year (have a week off next week
????).

Alle the best for you all list readers ????

-----Original Message-----
From: David Lang <david@lang.hm>
Sent: Wednesday, December 23, 2020 11:53 PM
To: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
Cc: Mariusz Kruk <mkr@safecomp.com>
Subject: Re: [rsyslog] TLS is killing me ;-)

No, currently rsyslog only supports using a single cert across everything

There are enhancement requests in to expand this, but I don't think any of
them cover the problem of accepting multiple certs to facilitate a
transition from one cert to another on the other end.

David Lang

On Wed, 23 Dec 2020, Mariusz Kruk via rsyslog wrote:

> Date: Wed, 23 Dec 2020 08:21:27 +0100 (CET)
> From: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
> To: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
> Cc: Mariusz Kruk <mkr@safecomp.com>
> Subject: Re: [rsyslog] TLS is killing me ;-)
>
> Thanks for the heads-up. It's probably due some time in the future but
> it'll require some good testing first. I won't roll-out into
> production lightly since we're having something like 500GB of logs
> daily ????
> After some thinking I realized one more thing. I can of course "go
> upstream"
> with the CA's and try to authenticate with chained certs and keep only
> root CA, not the whole trustchain on the receiver but still there'll
> come a day when rootCA cert expires and I'll have to switch to a new
> one. So eventually I will have to have a possibility to have at least
> two different CA's to verify clients' certs with.
> Is it at all possible?
>
>
>
> -----Original Message-----
> From: David Lang <david@lang.hm>
> Sent: Tuesday, December 22, 2020 6:10 PM
> To: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
> Cc: Mariusz Kruk <mkr@safecomp.com>
> Subject: Re: [rsyslog] TLS is killing me ;-)
>
> just as a FYI, 8.2010 includeed some pretty significant TLS
> improvements. I don't think they are related to what you are fighting,
> but I think you will want to upgrade (at least on the receiver)
>
> David Lang
>
> On Tue, 22 Dec 2020, Mariusz Kruk via rsyslog wrote:
>
>> Date: Tue, 22 Dec 2020 12:45:03 +0100 (CET)
>> From: Mariusz Kruk via rsyslog <rsyslog@lists.adiscon.com>
>> To: rsyslog@lists.adiscon.com
>> Cc: Mariusz Kruk <mkr@safecomp.com>
>> Subject: [rsyslog] TLS is killing me ;-)
>>
>> I'm having a distributed setup using a central "collector" and many
>> "small" rsyslog instances receiving events on remote locations.
>>
>> Those small sites send events "upstream" using TLS-protected RELP
>> with mutual cert-based authentication.
>>
>> Problem is, I used to have trustchain working like that: "CA1 -> CA2
>> ->
>> CA3 -> client cert". And it worked for many clients (around two
>> dozens, I believe). I had "CA1 -> CA2 -> CA3" provided as trust chain
>> on both side of the connection (both in imrelp and omrelp
>> configuration as tls.CACert
>> parameter) and just gave plain client cert as tls.MyCert.
>>
>> Worked great until now because I sudenly created CSR to the CA and
>> got in response a cert with a different chain - "CA2 -> CA4 -> client
>> cert".
>> Obviously when I configure my client with this cert, it's not valid
>> becaues the CA4 cert cannot be authenticated by the other end.
>>
>> Do I have any other option than to simply reconfigure all ends to use
>> CA1 as CACert and append CAs to client certs to make them chained
>> certs? Of course since I have already many clients deployed I'd
>> really like to avoid that but if there's no other choice.
>>
>> I'm using:
>>
>> # rpm -q rsyslog
>>
>> rsyslog-8.2001.0-3.el7.x86_64
>>
>> TIA for any words of advice.
>>
>>
>>
>> _______________________________________________
>> 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.