Bodo Moeller wrote:
First. Thank you very much for your answers. :)
> > * Error reporting?
> >
> > There seem to be several way to check for errors.
> > There is the ERR_get_error() (does this clear the error?)
>
> Actually it's not just one error, there's a list of them.
> You call ERR_get_error again and again until it returns 0.
> Sometimes in error situations the error quere can even be empty,
> and somtimes it might contain more than one item.
Ok, is there some "algoritm" to filter out the "most important error" -
for example to decide what action to take?
> > If I change the list of preferred ciphers so that the client and the
> > server has no common cipher (the server is an export version of MS
> > IIS) then SSL_connect() returns -1, SSL_get_verify_result() returns 0
> > (reasonable - there has been no cert verification yet) but
> > ERR_get_error() returns 0 (isn't that supposed to be the code for
> > OK?).
> No, it does not mean "no error". It just means that the error stack
> is empty. SSL_read and SSL_write don't usually write something on the
> error stack (although this can happen under certain circumstances);
> SSL_get_error tells you that something went wrong, and then details
> *may* be available via ERR_get_error().
>
> > SSL_get_error() returns 6. Where do I look for a #define to
> > match that error? (the only thing I can see in ssl.h is
> > SSL_ERROR_ZERO_RETURN and that seems pretty confusing).
>
> SSL_ERROR_ZERO_RETURN can happen only if the return value passed to
> SSL_get_error is 0 (see ssl_lib.c). It means that the connection was
> closed.
I thought about this and probably MS IIS just close the connection if no
common ciphers are available.
> You can use SSL[_CTX]_set_verify_depth (unless you are using OpenSSL
> 0.9.2b or earlier, which you include filenames suggest). Then you
> don't have to define a verification callback just to limit chain
> depth (but unfortunately the internal verification function does not
> produce X509_V_ERR_CERT_CHAIN_TOO_LONG when this depth is exceeded,
> instead it tries to verify the truncated chain, which will result
> in some other error code).
Ok. Say that I will use my callback-function to produce a
X509_V_ERR_CERT_CHAIN_TOO_LONG - how do I get a hold of the value set
with SSL_set_verify_depth (or the CTX-function) so I can compare it with
the X509_STORE_CTX_get_error_depth(X509_STORE_CTX *) function?
> This does not work. SSL_pending never reads data from the network, it
> just looks if there are leftovers from previous SSL_read's buffered
> internally. You always have to use SSL_read to get something done;
> if you want to avoid blocking, you have to set the underlying sockets
> into non-blocking mode.
Ok. But if use non-blocking I/O I must handle that the SSL_read() might
return 0 althought the select()-call (or similar) said that data was
available (maybe the data couldn't be decrypted or something like that)
- am I right?
s = SSL_pending() just says that "your next call to read will return at
least s bytes without blocking" or rather could be used in this kind of
loop:
numbytes = SSL_read(...);
while (SSL_pending() != 0) {
numbytes = SSL_read(...); // append to buffer
}
to read all data currently available (plus what have might come in extra
due to each SSL_read-call), right?
Regards Jesper
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
