Mailing List Archive: Does HUP signal cause a TLS certificate reload?

Does HUP signal cause a TLS certificate reload?

Dec 30, 2023, 5:42 AM

Post #1 of 4 (106 views)

Hi,

I'm using rsyslog as packaged by Debian 12 (bookworm). I'm logging
to central servers:

$DefaultNetstreamDriver gtls
[…]
*.* @@server.example.com:10514

I'm using client TLS certificates that expire after 3 months. I have
automation to put the updated certificate files in place, but if I
do not restart rsyslog then it does not pick up the new certificates
and eventually the client rsyslog is rejected and cannot re-connect.

I can easily restart rsyslog when new certificate files are put in
place, but then I get logs like this from every client host (many):

2023-12-30T02:32:01.521137+00:00 client1.example.com rsyslogd: omfwd: remote server at server.example.com:10514 seems to have closed connection. This often happens when the remote peer (or an interim system like a load balancer or firewall) shuts down or aborts a connection. Rsyslog will re-open the connection if configured to do so (we saw a generic IO Error, which usually goes along with that behaviour). [v8.2302.0 try https://www.rsyslog.com/e/2027 ]
2023-12-30T02:32:01.531001+00:00 client1.example.com rsyslogd: action 'action-19-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2302.0 try https://www.rsyslog.com/e/2007 ]
2023-12-30T02:32:02.327418+00:00 client1.example.com rsyslogd: action 'action-19-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2302.0 try https://www.rsyslog.com/e/2359 ]

So my simple question is, if I instead send a HUP signal to rsyslog,
will it rel;oad its updated TLS certificate files?

Or, is there another graceful way to do that?

The above log lines seem harmless but they trip my monitoring and I
would rather not programmatically ignore them as I may end up
ignoring a real problem later on.

Thanks,
Andy
_______________________________________________
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: Does HUP signal cause a TLS certificate reload? [ In reply to ]

rsyslog at lists

Dec 30, 2023, 6:19 AM

Post #2 of 4 (106 views)

Permalink

I believe restarting is the only way possible to achieve this. Certificates are connection based and therefore you must force the client to re-establish the connection to pickup the new certificate.

The client messages are therefore expected and should not be considered an error.

Regards,

> On Dec 30, 2023, at 07:42, Andy Smith via rsyslog <rsyslog@lists.adiscon.com> wrote:
>
> Hi,
>
> I'm using rsyslog as packaged by Debian 12 (bookworm). I'm logging
> to central servers:
>
> $DefaultNetstreamDriver gtls
> […]
> *.* @@server.example.com:10514
>
> I'm using client TLS certificates that expire after 3 months. I have
> automation to put the updated certificate files in place, but if I
> do not restart rsyslog then it does not pick up the new certificates
> and eventually the client rsyslog is rejected and cannot re-connect.
>
> I can easily restart rsyslog when new certificate files are put in
> place, but then I get logs like this from every client host (many):
>
> 2023-12-30T02:32:01.521137+00:00 client1.example.com rsyslogd: omfwd: remote server at server.example.com:10514 seems to have closed connection. This often happens when the remote peer (or an interim system like a load balancer or firewall) shuts down or aborts a connection. Rsyslog will re-open the connection if configured to do so (we saw a generic IO Error, which usually goes along with that behaviour). [v8.2302.0 try https://www.rsyslog.com/e/2027 ]
> 2023-12-30T02:32:01.531001+00:00 client1.example.com rsyslogd: action 'action-19-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2302.0 try https://www.rsyslog.com/e/2007 ]
> 2023-12-30T02:32:02.327418+00:00 client1.example.com rsyslogd: action 'action-19-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2302.0 try https://www.rsyslog.com/e/2359 ]
>
> So my simple question is, if I instead send a HUP signal to rsyslog,
> will it rel;oad its updated TLS certificate files?
>
> Or, is there another graceful way to do that?
>
> The above log lines seem harmless but they trip my monitoring and I
> would rather not programmatically ignore them as I may end up
> ignoring a real problem later on.
>
> Thanks,
> Andy
> _______________________________________________
> 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: Does HUP signal cause a TLS certificate reload? [ In reply to ]

rsyslog at lists

Dec 30, 2023, 4:03 PM

Post #3 of 4 (104 views)

Permalink

a HUP will reconnect, but I don't think that a HUP will reload the certificates
from disk.

David Lang

On Sat, 30 Dec 2023, John Chivian via rsyslog wrote:

> I believe restarting is the only way possible to achieve this. Certificates are connection based and therefore you must force the client to re-establish the connection to pickup the new certificate.
>
> The client messages are therefore expected and should not be considered an error.
>
> Regards,
>
>
>
>> On Dec 30, 2023, at 07:42, Andy Smith via rsyslog <rsyslog@lists.adiscon.com> wrote:
>>
>> Hi,
>>
>> I'm using rsyslog as packaged by Debian 12 (bookworm). I'm logging
>> to central servers:
>>
>> $DefaultNetstreamDriver gtls
>> […]
>> *.* @@server.example.com:10514
>>
>> I'm using client TLS certificates that expire after 3 months. I have
>> automation to put the updated certificate files in place, but if I
>> do not restart rsyslog then it does not pick up the new certificates
>> and eventually the client rsyslog is rejected and cannot re-connect.
>>
>> I can easily restart rsyslog when new certificate files are put in
>> place, but then I get logs like this from every client host (many):
>>
>> 2023-12-30T02:32:01.521137+00:00 client1.example.com rsyslogd: omfwd: remote server at server.example.com:10514 seems to have closed connection. This often happens when the remote peer (or an interim system like a load balancer or firewall) shuts down or aborts a connection. Rsyslog will re-open the connection if configured to do so (we saw a generic IO Error, which usually goes along with that behaviour). [v8.2302.0 try https://www.rsyslog.com/e/2027 ]
>> 2023-12-30T02:32:01.531001+00:00 client1.example.com rsyslogd: action 'action-19-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2302.0 try https://www.rsyslog.com/e/2007 ]
>> 2023-12-30T02:32:02.327418+00:00 client1.example.com rsyslogd: action 'action-19-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2302.0 try https://www.rsyslog.com/e/2359 ]
>>
>> So my simple question is, if I instead send a HUP signal to rsyslog,
>> will it rel;oad its updated TLS certificate files?
>>
>> Or, is there another graceful way to do that?
>>
>> The above log lines seem harmless but they trip my monitoring and I
>> would rather not programmatically ignore them as I may end up
>> ignoring a real problem later on.
>>
>> Thanks,
>> Andy
>> _______________________________________________
>> 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: Does HUP signal cause a TLS certificate reload? [ In reply to ]

rsyslog at lists

Dec 31, 2023, 1:59 AM

Post #4 of 4 (104 views)

Permalink

It will not.

Rainer

El dom, 31 dic 2023 a las 1:03, David Lang via rsyslog
(<rsyslog@lists.adiscon.com>) escribió:
>
> a HUP will reconnect, but I don't think that a HUP will reload the certificates
> from disk.
>
> David Lang
>
> On Sat, 30 Dec 2023, John Chivian via rsyslog wrote:
>
> > I believe restarting is the only way possible to achieve this. Certificates are connection based and therefore you must force the client to re-establish the connection to pickup the new certificate.
> >
> > The client messages are therefore expected and should not be considered an error.
> >
> > Regards,
> >
> >
> >
> >> On Dec 30, 2023, at 07:42, Andy Smith via rsyslog <rsyslog@lists.adiscon.com> wrote:
> >>
> >> Hi,
> >>
> >> I'm using rsyslog as packaged by Debian 12 (bookworm). I'm logging
> >> to central servers:
> >>
> >> $DefaultNetstreamDriver gtls
> >> […]
> >> *.* @@server.example.com:10514
> >>
> >> I'm using client TLS certificates that expire after 3 months. I have
> >> automation to put the updated certificate files in place, but if I
> >> do not restart rsyslog then it does not pick up the new certificates
> >> and eventually the client rsyslog is rejected and cannot re-connect.
> >>
> >> I can easily restart rsyslog when new certificate files are put in
> >> place, but then I get logs like this from every client host (many):
> >>
> >> 2023-12-30T02:32:01.521137+00:00 client1.example.com rsyslogd: omfwd: remote server at server.example.com:10514 seems to have closed connection. This often happens when the remote peer (or an interim system like a load balancer or firewall) shuts down or aborts a connection. Rsyslog will re-open the connection if configured to do so (we saw a generic IO Error, which usually goes along with that behaviour). [v8.2302.0 try https://www.rsyslog.com/e/2027 ]
> >> 2023-12-30T02:32:01.531001+00:00 client1.example.com rsyslogd: action 'action-19-builtin:omfwd' suspended (module 'builtin:omfwd'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2302.0 try https://www.rsyslog.com/e/2007 ]
> >> 2023-12-30T02:32:02.327418+00:00 client1.example.com rsyslogd: action 'action-19-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.2302.0 try https://www.rsyslog.com/e/2359 ]
> >>
> >> So my simple question is, if I instead send a HUP signal to rsyslog,
> >> will it rel;oad its updated TLS certificate files?
> >>
> >> Or, is there another graceful way to do that?
> >>
> >> The above log lines seem harmless but they trip my monitoring and I
> >> would rather not programmatically ignore them as I may end up
> >> ignoring a real problem later on.
> >>
> >> Thanks,
> >> Andy
> >> _______________________________________________
> >> 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.