Hello everyone. Wanted
to first send a huge thank you to everybody for this kick-@$$
software. I have been evangelizing its use since hell, the
earliest releases in the late 90's. Built everything from global
anycast aggregators to single-instances and everything betweeen.
I do have a question however about TLS handling. I have a client
that has a request to have frequent health-checks for the validity
of their certificates throughout their infrastructure
(OMD/naemon/custom plugins to the rescue). I have this working
great for common services that can be checked via some scripts
utilizing 'openssl s_client -connect' and parsing the output.
Where I am stumbling into some trouble though is in monitoring the
TLS certificate being served via their syslog-ng [syslog-ng 4
(4.8.1) on Debian 13] that is aggregating/receiving logs.
Via some debugging I found that using 'openssl s_client' can cause
some 'hung' TLS communication as it does not cleanly send the
expected 'eof' when closing the connection as I am checking via
tcp/6514 instead of say, one of the in-built tls handshakes in
openssl (smtp, imap, ldap, etc). Not at all syslog-ng's problem,
I understand.
[reference: https://ithy.com/article/fix-openssl-error0a000126-for-ssl-8w813fv2]
I have had some success in instructing the the receiver to more
gracefully handle this condition by adding 'Options =
SSL_OP_IGNORE_UNEXPECTED_EOF' to openssl.conf as well as including
the openssl option '-no_ign_eof' in my socket check. By "some
success", I mean the socket responds a little bit longer, but
still fails. Again, still openssl's issue, I understand. I am
investigating other methods such as gnutls-cli, etc but haven't
(yet) found anything that returns the certificate data itself for
grokking out the 'notAfter' value of the certificate.
The reason I am asking here is to see if anyone else has found
and/or solved for similar behavior since it appears thus far that
it is syslog-ng and the 'tls' option that seem to be what is
ceasing to respond after some time. When I have done these
certificate checks against other daemons that lack the in-built
tls handshakes in openssl and they continue responding with
certificate data whereas syslog-ng starts choking on the
"error:0A000126:SSL routines::unexpected eof while reading Unable
to establish SSL connection" until the daemon gets restarted, then
all responds again appropriately. I've run the following and the
syslog-ng tls only responds properly for approx 70 seconds and
starts failing.
for ((i=1;i>0;i++)); do echo "===[ `date`"; openssl s_client
-connect dmz-log.DOMAIN.com:6514 -no_ign_eof < /dev/null
2>&1 | openssl x509 -enddate -noout; sleep 10; done
==========
===[ Thu Jun 4
03:09:08 PM PDT 2026
notAfter=Aug 8 05:37:10 2026 GMT
===[ Thu Jun 4 03:09:18 PM PDT 2026
Could not find certificate from <stdin>
40770E8A267F0000:error:1608010C:STORE
routines:ossl_store_handle_load_result:unsupported:../crypto/store/store_result.c:160:provider=default
==========
Anybody with any insights or that may have found a way to solve
for this, I would greatly appreciate any hints.
Thanks so much,
-Chris
--
Node-Nine, Inc.
chris@node-nine.com
619.354.6463