>>> But anyway I think that it shouldn't be necessary to use a verify
>>> callback function. I've recently added functions to the SSL API that
>>> allow defining a verification depth, because this is something that
>>> the library should be able to do, and there _is_ support for it in the
>>> X.509 library (but the X.509 library does not yet produce the right
>>> error code when the length is exceeded).
>> I don't think handling the depth internally (which is a good thing)
>> completely removes the need for a callback.
>> Another reason for requiring
>> a callback is to obtain the certificate status. This could be achieved
>> with a certificate status callback. With the code as it stands today,
>> however, the best place to verify the status of the certificate would
>> seem to be in the verify callback.
For very special needs you will always have to use (and will be able
to use) an application-defined callback function, of course. But
commonly used functionality should be in the library.
What you can do without a callback now is get the verification result
(SSL_get_verify_result, with return values such as
X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT,
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT[_LOCALLY],
X509_V_ERR_CERT_HAS_EXPIRED, and in the future also
X509_V_ERR_CERT_CHAIN_TOO_LONG [you'll now get
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT[_LOCALLY] instead of this one])
and the peer's certificate and certificate chain
(SSL_get_peer_certificate, SSL_get_peer_cert_chain).
For typical applications these functions should be enough.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
