[[EMAIL PROTECTED] - Fri Jan 3 08:21:38 2003]:
> When a non-blocking SSL_accept() returns -1 with SSL_ERROR_WANT_READ
> or
> SSL_ERROR_WANT_WRITE set, the appropriate thing to do is to call
> SSL_accept() again.
>
> This is fine, but the current state machine in ssl3_accept() doesn't
> seem to keep track of the fact that the callback may have succeeded
> already, causing the callback to be called again when SSL_accept() is
> retried.
>
> Is there some way around this that I'm missing? If not, wouldn't it
be
> desirable to add something like this to the state machine in
> ssl3_accept()?
>
> I'm sure there are some cases where the callback should be called
> again
> (renegotiations, for example).
I have analyzed your request. For me it seems, that s3_srvr.c already
contains all the code necessary: the certificate is verified only once
by ssl3_get_client_certificate() which is handled by its own state.
It calls ssl_verify_cert_chain(), which performs the verification of
the complete chain in one operation without being influenced by a
blocking or non-blocking setup.
I am using a non-blocking setup myself in Postfix/TLS and did not
observe the verify_callback() being called twice for the same purpose.
However: the verify_callback() can be called several times during the
certificate chain verification. It is called at least once for each
certificate in the chain (even in case of success) and may be called
more than once per certificate for different verification failures
(e.g. certificate expired, signature failure, etc).
Did you make sure, that your report is not caused by the latter
behaviour?
Best regards,
Lutz
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]