On 02/19/2013 02:33 PM, Dr. Stephen Henson wrote:
On Tue, Feb 19, 2013, Jeremy Harris wrote:
On 18/02/2013 22:32, Dr. Stephen Henson wrote:
That's fine except that we're using SSL_CTX_set_verify() callback already
and the docs say it and SSL_CTX_set_cert_verify_callback() should not
be mixed.
That explanation could be clearer. In this case it's fine to mix the two.
OK, thankyou. Now, about the need for a store for the OCSP verify?
You can disable verification altogether with the OCSP_NOVERIFY flag to
OCSP_basic_verify, it should then never reference the passed store and it can
be NULL.
That's fine if the OCSP response has been signed by a CA in the
server certificate chain as that chain has already been verified.
(which last is a requirement of the Stapling RFC, if I understand)
So I'm still confused. What does OCSP_NOVERIFY disable and what
remains? If it stops the checking of the signing chain of the stapling,
how is the case of a subverted server, which has a valid-but-revoked
certificate,
handled? It would seem that my client would successfully verify the
original server certificate and the content of stapling (invented by the now
malicious server to claim that the server certificate is still valid).
--
Thanks,
Jeremy
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
