Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of DRuggeri@primary.net designates
 216.87.38.221 as permitted sender)
Message-ID: <4E652A1B.8020106@primary.net>
Date: Mon, 05 Sep 2011 14:59:23 -0500
From: Daniel Ruggeri <DRuggeri@primary.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
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>
In-Reply-To: <4E64F9A3.6040304@velox.ch>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 9/5/2011 11:32 AM, Kaspar Brand wrote:
> 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.

Yes, I like the suggestion. I added some constraints to what I was doing
by trying to design a function that would take X509_INFO so the function
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'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?).


On 9/5/2011 11:52 AM, Dr Stephen Henson wrote:
> Potential gotcha is that you end up loading up client CAs in the trusted
> certificate store which isn't always what you want. For example if that context
> gets reused they'll be trusted server CA certificates later.

I would say that a case where a server admin doesn't wish to trust
issuers of their own certs is remote, but possible. I think an
appropriately worded blurb in the documentation would be important.
Also, since this functionality hasn't existed yet, I'm inclined to think
that even fewer folks would be impacted.
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.

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.


I'll clean up the work and update trunk as well as the 2.2 backport
patch sometime later this week.


static void ssl_init_proxy_certs(server_rec *s,
                                 apr_pool_t *p,
                                 apr_pool_t *ptemp,
                                 modssl_ctx_t *mctx)
{
    int n, ncerts = 0;
    STACK_OF(X509_INFO) *sk;
    STACK_OF(X509) *chain;
    X509_STORE_CTX *sctx;
    X509_STORE *store = SSL_CTX_get_cert_store(mctx->ssl_ctx);
    modssl_pk_proxy_t *pkp = mctx->pkp;

/* ... */

    if (!pkp->ca_cert_file || !store) {
        return;
    }

    /* Load all of the CA certs and construct a chain */
    pkp->ca_certs = (STACK_OF(X509) **) apr_pcalloc(p, ncerts * sizeof(sk));
    sctx = X509_STORE_CTX_new();

    if (!sctx) {
        ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s,
                     "SSL proxy client cert initialization failed");
        ssl_log_ssl_error(APLOG_MARK, APLOG_ERR, s);
        ssl_die();
    }

    X509_STORE_load_locations(store, pkp->ca_cert_file, NULL);

    for (n = 0; n < ncerts; n++) {
        int i;
        X509_INFO *inf = sk_X509_INFO_value(pkp->certs, n);
        X509_STORE_CTX_init(sctx, store, inf->x509, NULL);
        X509_verify_cert(sctx);
        ERR_clear_error();

        chain = X509_STORE_CTX_get1_chain(sctx);
        sk_X509_shift(chain);
        i=sk_X509_num(chain);
        pkp->ca_certs[n] = chain;
        X509_STORE_CTX_cleanup(sctx);

        ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
                     "client certificate %i has loaded %i "
                     "intermediate CA%s", n, i, i == 1 ? "" : "s");
    }

    X509_STORE_CTX_free(sctx);
}

-- 
--
Daniel Ruggeri