httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <>
Subject Re: [RFC] Enable OCSP Stapling by default in httpd trunk
Date Sun, 06 Sep 2015 13:13:05 GMT
On 05.09.2015 14:23, Jeff Trawick wrote:
> On 09/04/2015 10:59 AM, Kaspar Brand wrote:
>>> 1. The default configuration should not trigger unsolicited outgoing
>>> queries to untrusted systems, for both a) and b), that's how I would put it.
> Re: "unsolicited":
> Key words/phrases from the other end of the continuum: "unexpected by 
> many", "responder obtained from explicitly configured certificate"

The other end of the continuum would be "explicitly requested", in my
view. "unsolicited" = "not explicitly requested", that's what I intended
to say (and "explicitly" referring to something like "manually enabling
a directive").

> The unexpected aspect could be helped by a [notice] message at startup 
> indicating that an OCSP responder will be contacted for N certificates 
> due to the directive.  (If there is only one, an alternate message could 
> be displayed with the actual responder URL; we couldn't do that for 
> arbitrary numbers.)

IMO, not a sufficient method for justifying a "default on" setting
(configuring a Base64 encoded certificate blob through
SSLCertificateFile doesn't amount to explicitly configuring a responder

> Re: "untrusted":
> The certificate and its content are untrusted in general?

Technically speaking, as long as mod_ssl doesn't validate the cert file
against a set of (locally configured) trust anchors, the complete file
is to be considered untrusted. An admin could have received a "fake
reply" for his CSR, where the public key perfectly matches the private
key, but the contents are bogus otherwise. Sure, he would most likely
realize this quite soon after having configured the cert and trying to
connect to his own server, but essentially, I wouldn't consider the
contents pointed to by an SSLCertificateFile directive as trusted.

> The content 
> is trusted but the responder URL is not what/who it seems? (I wasn't 
> sure where you were leading when you alluded to this in prior 
> correspondence.)

X.509v3 certs can have all sorts of "useful" extensions, and I wouldn't
consider all this information automatically trusted just because it's
signed by the CA (take the OU field in the subject DN as an example:
most CAs will have disclaimers stating that these fields are basically

With the OCSP URI in particular, an additional aspect of "untrusted" is
that resolving its IP address(es) relies on the DNS, i.e. a component
which can't be considered trusted when it is queried for records of
third-party domains.


View raw message