httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <httpd-dev.2...@velox.ch>
Subject Re: svn commit: r1160863 - in /httpd/httpd/trunk: docs/manual/mod/ modules/ssl/
Date Mon, 05 Sep 2011 16:32:35 GMT
On 03.09.2011 22:39, Daniel Ruggeri wrote:
> updated method I'm using. Rather than storing the chain as
> STACK_OF(X509_INFO) I have switched to STACK_OF(X509) and am using the
> following function to build the chain.
> Comments are definitely appreciated as I don't have a very good frame of
> reference for using X509_verify_cert().

Switching to STACK_OF(X509) is the right thing, yes (you don't need
X509_INFO and its additional fields for the CA certs). After having
looked at ssl_init_proxy_certs() and ssl_callback_proxy_cert() a bit
more closely, I think some additional changes might be needed.

Thanks to your patch, ssl_callback_proxy_cert() will now pick the proper
cert even if the ca_list does not include the DN of the CA which signed
the cert, which is definitely an improvement. There's still one
drawback, though, IINM: for proxy connections, mod_ssl currently won't
include the intermediate CA certs of its client cert(s) in outgoing
connections.

As SSL_CTX_set_client_cert_cb(3) states:

       The client_cert_cb() cannot return a complete certificate
       chain, it can only return one client certificate. If the
       chain only has a length of 2, the root CA certificate may
       be omitted according to the TLS standard and thus a stan-
       dard conforming answer can be sent to the server. For a
       longer chain, the client must send the complete chain
       (with the option to leave out the root CA certificate).
       This can only be accomplished by either adding the inter-
       mediate CA certificates into the trusted certificate
       store for the SSL_CTX object (resulting in having to add
       CA certificates that otherwise maybe would not be
       trusted), or by adding the chain certificates using the
       SSL_CTX_add_extra_chain_cert(3) function, which is only
       available for the SSL_CTX object as a whole and that
       therefore probably can only apply for one client certifi-
       cate, making the concept of the callback function (to
       allow the choice from several certificates) questionable.

SSL_CTX_add_extra_chain_cert() isn't an option for us, I assume, so the
best we can probably do in ssl_init_proxy_certs()) is to load the certs
specified via ProxyMachineCertificateChainFile with
X509_STORE_load_locations and rely on OpenSSL's "auto chain building"
afterwards.

Populating the mctx->pkp->ca_certs stacks is still required, however,
since these are needed in the callback to figure out the correct client
cert.

Attached is an *untested* patch which hopefully gives you an idea of the
approach I'm suggesting (you might still want to separate the chain
building into a function of its own, I simply left t inline in
ssl_init_proxy_certs for easier editing). Not sure if it works, but
would appreciate if you could give it a try.

Kaspar

Mime
View raw message