How to manage the error queue in openssl (SSL_get_error and ERR_get_error)

Question

In OpenSSl, The man pages for The majority of SSL_* calls indicate an error by returning a value <= 0 and suggest calling SSL_get_error() to get the extended error.

But within the man pages for these calls as well as for other OpenSSL library calls, there are vague references to using the "error queue" in OpenSSL - Such is the case in the man page for SSL_get_error:

   The current thread's error queue must be empty before the TLS/SSL I/O
   operation is attempted, or  SSL_get_error() will not work reliably.

And in that very same man page, the description for SSL_ERROR_SSL says this:

   SSL_ERROR_SSL
       A failure in the SSL library occurred, usually a protocol error.
       The OpenSSL error queue contains more information on the error.

This kind of implies that there is something in the error queue worth reading. And failure to read it makes a subsequent call to SSL_get_error unreliable. Presumably, the call to make is ERR_get_error.

I plan to use non-blocking sockets in my code. As such, it's important that I reliably discover when the error condition is SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE so I can put the socket in the correct polling mode.

So my questions are this:

• Does SSL_get_error() call ERR_get_error() implicitly for me? Or do I need to use both?

• Should I be calling ERR_clear_error prior to every OpenSSL library call?

• Is it possible that more than one error could be in the queue after an OpenSSL library call completes? Hence, are there circumstances where the first error in the queue is more relevant than the last error?

Answer 1

• SSL_get_error does not call ERR_get_error. So if you just call SSL_get_error, the error stays in the queue.
• You should be calling ERR_clear_error prior to ANY SSL-call(SSL_read, SSL_write etc) that is followed by SSL_get_error, otherwise you may be reading an old error that occurred previously in the current thread.