Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4E65ADD6.50301@velox.ch>
Date: Tue, 06 Sep 2011 07:21:26 +0200
From: Kaspar Brand <httpd-dev.2011@velox.ch>
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: svn commit: r1160863 - in /httpd/httpd/trunk: docs/manual/mod/
 modules/ssl/
References: <20110823193508.9E41A2388A02@eris.apache.org>
 <4E61C3CE.4020500@velox.ch> <4E625521.3000905@opensslfoundation.com>
 <4E629093.1090302@primary.net> <4E64F9A3.6040304@velox.ch>
 <4E652A1B.8020106@primary.net>
In-Reply-To: <4E652A1B.8020106@primary.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 05.09.2011 21:59, Daniel Ruggeri wrote:
> could be reused to build a chain for the server-side of mod_ssl (because
> today, the chain certs get presented in whatever order they are in the
> file resulting in unhappy java clients). With a little bit of
> refactoring on the server side, this could be taken care of just as well.

I agree, this is definitely desirable, and we should certainly do it for
trunk. As suggested by Steve, we shouldn't simply ignore all
X509_verify_cert errors in this case, too. Something like
modssl_check_cert(), which returns a proper chain on success, would be
my idea.

> I've made a few adjustments and built/tested the snippet below. Works
> well, though in my test cases I can't tell if the chain is being sent or
> not (suggestions on how to verify?).

If you have a proxied server which runs httpd/mod_ssl, then you can use
the SSLOptions +ExportCertData, and look for the SSL_CLIENT_CERT_CHAIN_n
environment vars.

> A potential solution to this is to create a directive controlling
> whether a new NULL context is used when loading the store or the
> existing SSL context. In the documentation for both directives, we could
> inform the server admin the impact of either decision.

I'm somewhat reluctant towards adding even more config knobs, but if
it's unavoidable... too bad extra chain certs can't be set at the SSL*
level.

> FWIW, RFC 2246 (SSL 3.1/TLS 1.0), RFC 4346 (SSL 3.2/TLS 1.1) and RFC
> 5246 (SSL 3.3/TLS 1.2) place no requirements on sending a chain aside
> from making it clear that a chain can be sent. I would say for the
> largest range of compatibility, a chain should be sent, but it's not a
> requirement if it makes the server admin uncomfortable with the openssl
> trust side effect.

It might be a wording issue (there's no explicit MUST), but the
statement under the "Meaning of this message" in RFC 5246 makes it
relatively clear that you're expected to send a chain (you may omit the
root, yes, but not the intermediates).

If we're the client, then it's definitely in our interest to send the
chain, I think - otherwise you would have to ask the server admin to
explicitly add our intermediate CA cert(s) to his store.

Kaspar