Dr S N Henson <[EMAIL PROTECTED]>:
>> if (X509_verify(xs,pkey) <= 0)
>> + /* XXX For the final trusted self-signed cert,
>> + * this is a waste of time. That check should
>> + * optional so that e.g. 'openssl x509' can be
>> + * used to detect invalid self-signatures, but
>> + * we don't verify again and again in SSL
>> + * handshakes and the like once the cert has
>> + * been declared trusted. */
>> {
>> ctx->error=X509_V_ERR_CERT_SIGNATURE_FAILURE;
>> ctx->current_cert=xs;
> If I recall that bit of code I don't think the check will happen more
> than once: though more by luck than design.
>
> If the certificate verifies the first time it will have its 'valid'
> field set to 1.
>
> The root certificate will always be looked up and will then be placed in
> the X509_STORE cache so subsequent lookups will always return the same
> structure. This should mean that the check on the 'valid' field will
> bypass the signature check after the first successful call.
However this does not help forking servers where new connections
usually have to work with a fresh copy of the original X509_STORE
cache.
BTW, what is the CRYPTO_LOCK_X509_STORE lock good for? It is obtained
by X509_STORE_add_cert and X509_STORE_add_crl before adding something
to ctx->objs, but the code that looks up stuff from ctx->objs would
not be able to handle ctx->objs changing in the middle of things, so
you cannot use X509_STORE_add_cert and X509_STORE_add_crl in
multi-threaded programs. Well, this locking makes it possible to use
multiple threads to add stuff to the object cache of the same
X509_STORE, but I'm not sure why one would want to do that.
(As locking is per class and not per object, we have limited
concurrency for multiple threads adding objects to the caches
of *multiple* X509_STOREs, which is more likely to happen.)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
