> 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 t
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
> >>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 e
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 n
> 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_erro