On Fri, Jul 16, 1999 at 11:54:31AM +0200, Jesper Trägårdh wrote:
> Bodo Moeller wrote:
>> 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?
Well, no. All such errors are real errors, i.e. usually fatal;
unlike with errno, there's no EWOULDBLOCK or so in the OpenSSL error
queue, because the non-errors for non-blocking I/O are handled by
other means.
>> 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?
There's SSL_get_verify_depth, and ssl_verify_cert_chain sets a pointer
to the SSL structure by using X509_STORE_CTX_set_ex_data. For details
on how to do this, presumably you'll have to read the sources
(ssl/ssl_cert.c, crypto/x509/x509_vfy.h, crypto/x509/x509_vfy.c).
Actually, X509_verify_cert and internal_verify (in x509_vfy.c) both
should largely be rewritten because they make assumptions about
uniqueness of names that are not warranted, and don't know about X.509
v3 extensions.
>> 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?
SSL_read will return 0 only if the connection was closed, and -1 in
case of errors or EWOULDBLOCK and the like. Use SSL_get_error to
interpret the return value.
> 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?
Yes, I think so.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
