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