Arne Ansper wrote:
I just checked. Seems that SSL_CTX_use_certificate_chain_file has a same
problem. Other uses of ERR_peek_error seem to be immune to the old entries
in error stack.
One theory is that applications should not call arbitrary OpenSSL
functions while there is stuff in the error
Like I say, they should only do this if there was an error reported, surely?
No. Take a look at the SSL_CTX_use_certificate_chain_file:
ret=SSL_CTX_use_certificate(ctx,x);
if (ERR_peek_error() != 0)
ret = 0; /* Key/certificate mismatch doesn't imply ret==0 ... */
I guess
Bodo Moeller via RT wrote:
On Tue, Nov 26, 2002 at 10:44:15PM +0200, Arne Ansper wrote:
I just checked. Seems that SSL_CTX_use_certificate_chain_file has a same
problem. Other uses of ERR_peek_error seem to be immune to the old entries
in error stack.
One theory is that applications should
I just checked. Seems that SSL_CTX_use_certificate_chain_file has a same
problem. Other uses of ERR_peek_error seem to be immune to the old entries
in error stack.
One theory is that applications should not call arbitrary OpenSSL
functions while there is stuff in the error queue.
Adding ERR_clear_errors() into SSL_read() etc seems to be the correct
approach. It is already handled this way in _accept(), _connect(), but
not that obvious, because it is found e.g. in ssl3_accept() which is
called depending on the method selected.
You will often find ERR_clear_errors()
