httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dr Stephen Henson <>
Subject Re: [PATCH 55593] Add "SSLServerInfoFile" directive
Date Wed, 09 Oct 2013 13:52:31 GMT
On 09/10/2013 02:22, Trevor Perrin wrote:
> Hi Kaspar, Stephen,
> So I think where things stand is that the OpenSSL 1.0.2 branch is
> capable of handling ServerInfo on a per-algorithm basis, but it's not
> clear how to expose this through Apache.
> (My previous email was naive, I was thinking maybe Stephen was saying
> the "current certificate" / "current key" concept was already exposed
> through to Apache, but I don't think it is).

Technically the "current certificate" concept doesn't need exposing at all. You
just have to make sure you set all the relevant parameters *after* you set the
certificate they apply to and *before* you set another one.

> So is there some way I could implement mod_ssl support for ServerInfo
> without a major rewrite of how mod_ssl handles certs and keys? (which
> some of the previous suggestions seemed to entail...)

I can see two ways to do this.

One is to add some code to Apache that just covers ServerInfo and is a directive
at the same level as certificates (apologies, not sure what the actual term for
that is). You then make sure you apply the value of that directive when you set
the relevant certificate.

The other is to enhance the SSL_CONF code in Apache so it can also store
per-certificate parameters.

The SSL_CONF currently works in Apache is to store all the SSL_CONF commands in
an array during configuration and replay them when the SSL_CTX is set. That's OK
for parameters that apply to the whole server (which reminds me support for
client mode in Apache would be good too) but not for individual certificates.

What you'd do to extend this is to have an array stored at the certificate level
and replay it after the appropriate certificate is set.

It's tempting to just add a directive but after some thought I think expanding
Apache SSL_CONF handling is the way to go. This would add some future proofing
so we don't have to go through this all again in future.

Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775

View raw message