SSL_CTX_set_info_callback notification noise during TLS handshakes

Filtering Handshake Events in OpenSSL 3.x

To isolate critical failures from informational noise in the SSL_CTX_set_info_callback, filter the ret parameter first and then narrow the scope using the where parameter. In OpenSSL 3.x, a ret value of 1 typically indicates a successful state transition, while a value of 0 or less indicates an error or a need for more data.

Distinguishing Failures from Noise

The where parameter identifies the specific stage of the TLS state machine. To reduce noise, ignore all callbacks where ret == 1. To isolate actionable failures, monitor for ret <= 0 specifically during these states:

• SSL_CB_HANDSHAKE_DONE: Confirms the final result of the handshake.
• SSL_CB_HANDSHAKE_START: Useful for timing, but usually noise unless it fails immediately.

Note that certificate verification failures often trigger a failure in the general handshake flow rather than a specific where constant dedicated solely to X509 validation. Therefore, the most reliable pattern is to trigger your error-logging logic whenever ret <= 0 is encountered during the handshake phase.

Draining the Error Queue

Because OpenSSL maintains a thread-local error queue, failing to drain it will cause stale errors to be reported in subsequent callbacks. The recommended pattern is to loop through ERR_get_error() until the queue is empty.

void info_callback(const SSL *s, void *arg, int where, int ret) {
    if (ret <= 0) {
        unsigned long err;
        // Drain the queue to prevent duplicate/stale alerts
        while ((err = ERR_get_error()) != 0) {
            char buf[256];
            ERR_error_string_n(err, buf, sizeof(buf));
            // Log the specific error (e.g., certificate expired)
            fprintf(stderr, "TLS Error: %s\n", buf);
        }
    }
}

Implementation Assumptions

This approach assumes you are using OpenSSL 3.x and that the callback is executing within the same thread that performed the SSL operation. If your architecture offloads SSL processing to a separate thread pool, ERR_get_error() must be called in the context of the thread that encountered the error.

Diagnostic Detail Needed: Are you using a custom SSL_CTX_set_verify callback in addition to the info callback? If so, certificate-specific failures may be intercepted there before they reach the info callback's ret check.