infinite loop wildcard ssl certificate

[kamusin]

For some reason our rsyslog clients are entering in a never ending loop when we are using a commercial wildcard certificate. These are the last messages before to use 99% CPU and entering to this loop (I had to make a hard reboot to recover this server):

6176.209422062:main Q:Reg/w0 : actionDoRetry: action 0 action->tryResume returned -2006 6176.209424345:main Q:Reg/w0 : actionDoRetry: action 0 enter loop, iRetries=0 6176.209426542:main Q:Reg/w0 : actionDoRetry: action 0 action->tryResume returned -2006 6176.209432848:main Q:Reg/w0 : actionDoRetry: action 0 enter loop, iRetries=0 6176.209435220:main Q:Reg/w0 : actionDoRetry: action 0 action->tryResume returned -2006 6176.209437513:main Q:Reg/w0 : actionDoRetry: action 0 enter loop, iRetries=0 6176.209439703:main Q:Reg/w0 : actionDoRetry: action 0 action->tryResume returned -2006

Unfortunately this issue is not reproducible when we use our own certificates (generated locally in rsyslog server).

Server software version: rsyslog-8.10.0.ad1-1.el7.x86_64 rsyslog-relp-8.10.0.ad1-1.el7.x86_64

Client: rsyslog-relp-8.10.0.ad1-1.el7.x86_64 rsyslog-8.10.0.ad1-1.el7.x86_64

Client config:

#### MODULES ####

module(load="imuxsock") # provides support for local system logging (e.g. via logger command)
module(load="imklog")   # provides kernel logging support (previously done by rklogd)
module(load="imfile")   # loaded once for file input module
module(load="omrelp")   # RELP module for reliable outbound communications
action(type="omrelp" port="xxx" target="xx" tls="on" tls.caCert="xxx" tls.myCert="xx" tls.myPrivKey="xx" tls.authmode="name" tls.permittedpeer=["xxxxx"])

#### GLOBAL DIRECTIVES ####
# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
# Include all config files in /etc/rsyslog.d/
$IncludeConfig /etc/rsyslog.d/*.conf
#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
kern.*                                                 /var/log/kernel

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  /var/log/maillog

# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 :omusrmsg:*

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

*.* :omrelp:xxxx:xxxxx

If you need any other information please just ask me! Thanks

[rgerhards]

@alorbach can you pls check this out?

[alorbach]

This issue is very old, the question is if it is still valid. @kamusin would it be possible to get some of these commercial certificates in order to reproduce the issue (even expired certs) ?

[roblar540]

@alorbach I just ran into this running omrelp with OpenSSL towards a server with a self-signed certificate. Perhaps it could provide some clues.

Steps to reproduce On a fresh Debian bullseye:

# install rsyslog w/ relp
apt -yq install rsyslog rsyslog-relp

# configure action
cat<<EOF>/etc/rsyslog.d/01.conf
module(load="omrelp" tls.tlslib="openssl")
action(type="omrelp" target="127.0.0.1" port="1234")
EOF

# generate self-signed cert
openssl req -new -x509 -newkey rsa:4096 -keyout /tmp/test.key -out /tmp/test.crt -days 30 -subj '/CN=test.local'

# set up openssl listener on tcp/1234
openssl s_server -key /tmp/test.key -cert /tmp/test.crt -port 1234

# run in debug mode
rsyslogd -dn

My result doing this is an infinite loop maxing CPU load with the same errors given in the post above.