httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dr Stephen Henson <>
Subject Re: mod_ssl OCSP questions
Date Thu, 29 Nov 2007 21:35:40 GMT
Joe Orton wrote:
> Taking this discussion out of bugzilla.  As implemented currently the 
> OCSP validation is working like this:
> 1) trusted store T initialized with root certs configured via SSLCA*
> 2) foreach cert in chain from (root...client certificate):
>    a) verify cert is signed by trusted cert (or, is transitively so)
>    b) if so, perform OCSP validation on cert as follows:
>      i) pick a responder, exchange OCSP messages
>      ii) verify signature of OCSP response against certs in trusted 
>          store T
> I'm not familiar with how OCSP is typically deployed; my questions are:
> a) is it acceptable to assume that the same set of trusted certs is used 
> to verify the signature of the OCSP response as is used to verify the 
> client cert itself?  Or do these need to be separately configurable?

There are several techniques used.

1. Sign responses using the key from the CA that issued the cert(s)
being checked.

This isn't often done because it would involve the responder having
access to a certificate signing key.

2. Sign responses using a special certificate signed by the CA that
issued the cert(s) being checked.

This is by far the most common. It avoids the problems of 1 and
responses can be verified without additional configuration.

3. Sign responses using a key which is trusted by some out of band means.

This covers cases where (for example) a locate OCSP responder is used to
sign responses for a site or a responder will handle multiple
unconnected CAs.

OpenSSL supports #1 and #2 directly so these should be automatic if the
OpenSSL OCSP API has been used correctly.

A limited form of #3 is implemented in OpenSSL. A generalised version
might be more appropriate in some circumstances but would need
additional configuration options to implement.

> b) does it really make sense to be doing OCSP validation individually on 
> each cert in the peer's cert chain?  Marc mentioned an issue with a 
> compromised intermediary cert; but I want to be sure I understand this 
> properly.  Can someone explain the exact threat model which checking the 
> whole chain would be necessary for?

If the CA key is compromised (e.g. used once maliciously) then it can be
used to issue an OCSP responder certificate under #2 above. That could
be used in a bogus responder.

Some security policies don't consider this likely enough to check the
whole chain and just check the EE cert which is much more likely to be

I'd say making this configurable would be the best option.

> c) Steve mentioned some responders don't accept requests with nonces.  
> What is a sane default?  Send nonces (more secure), or not (better 
> interop).  From reading the RFC it looks like mod_ssl should also be 
> checking the validity times from the OCSP response, which would help, I 
> guess.

I'll check how we are using the API. There are some OCSP helper
functions in OpenSSL which check the appropriate times and allow a
configurable "skew" for cases where clocks are inaccurately set. How
much skew to allow in practice may again depend on local policy.

Dr Stephen N. Henson.
Core developer of the   OpenSSL project:
Freelance consultant see:
Email:, PGP key: via homepage.

View raw message