httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <>
Subject Re: [PATCH 55593] Add "SSLServerInfoFile" directive
Date Sun, 13 Oct 2013 09:29:19 GMT
On 11.10.2013 13:53, Dr Stephen Henson wrote:
> IMHO though there needs to be a way to be able to tie a directive to a
> certificate in mod_ssl anyway though. I'm surprised no one has needed to do that
> before.

I'm not sure we really need this for mod_ssl, as configuring more than
one cert per vhost is probably a very rare case (the number of non-RSA
certs on public sites is extremely small - in the 2010 SSL Survey from
Qualys e.g., a few more than 100 out of 600,000 were DSA [1]). If people
deliberately want to go for something other than RSA, I would assume
that they either omit the RSA cert completely, or set up a dedicated
vhost for (EC)DSA.

> Well moving the SSL_CONF_CMD block does have some consequences. I placed it at
> (what I think is) the last possible point for a reason: so the SSL_CONF could
> reset just about anything set by Apache.

Currently, it's at the end of ssl_init_ctx_protocol(), which happens
still relatively early when looking at what ssl_init_ConfigureServer()
does (which is used to configure a specific vhost): for server mode,
ssl_init_ConfigureServer() calls ssl_init_server_ctx(), which in turn calls:

  ssl_init_ctx(), which consists of
  ssl_init_server_certs(), which consists of
    ssl_server_import_cert(), once per type
    ssl_server_import_key(), once per type

My PoC places the SSL_CTX_use_certificate_chain_file() and
SSL_CTX_use_PrivateKey_file() calls in ssl_init_server_certs, which
should also work fine for applying all SSL_CONF stuff with
SSL_CONF_CTX_set_ssl_ctx, I think.

> I think at least some twiddling with ssl_pphrase_Handle() would be needed
> because Apache will (I think) choke if you have no certificates configured.

Yes and no - see the PoC I attached to my previous message, where I
simply disabled the code relying on the tPublicCert and tPrivateKey
hashes. As the name of ssl_pphrase_Handle() says, it's raison d'ĂȘtre is
essentially handling encrypted private keys - and I hope that for the
future, we could strip it down to the minimum required.



View raw message