httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Harris" <>
Subject RE: SSL mass-vhosting
Date Fri, 11 Jun 1999 20:41:10 GMT

Ralf Engelschall wrote:
> mod_ssl reads all cert/keys on init, correct. And it decides which one to
> on a per request, or more correct, on a per connection basis. But the
> you miss for "SSL mass virtual hosting" is this: EVERY DECISION you want
to do
> at the HTTP level for the "mass virtual hosting" WILL NOT WORK.  Why?
> you decide too late. The cert/key has to be already known _before_ any
> of HTTP request will be transferred over the network.  That's a chicken
> egg problem and I'm 99.5% sure you cannot adapt the old "mass virtual
> idea for HTTPS, at least not for solving the cert/key selection problem.
> would be happy when someone proofs me to be wrong, but I no chance here
> The only way this could be solves is when the SSL layer's Hello messages
> already contain the virtual host:port information. But SSLv3/TLSv1 doesn't
> support this.

I understand that the crt/key has to be picked _before_ any bytes of the
HTTP request are passed, an therefore we don't have the "Host:" header to
make the cert/key choice. That excludes making any virtual hosting choices
based on the host header - so host header based mass SSL hosting is out just
as SSL with host VirtualHosts is out. But we do have the ipaddr of the local
socket which we can get when the SSLv3/TLSv1 layer is being initialized - so
ipaddr SSL mass hosting is workable. (Just as ipaddr based SSL-VirtualHosts
work just fine.)

It seems to me the way to do this is two new directives analogous to
VirtualDocumentRootIP for mod_ssl: SSLCertificateFileIP and
SSLCertificateKeyFileIP. They would choose a crt/key based on the local
ipaddr of the incoming connection. Something like:

SSLCertificateFileIP /path/to/keydir/%0.crt
SSLCertificateKeyFileIP /path/to/keydir/%0.key

would be a workable mass-SSL-hosting configuration.

But this gets sticky fast: mod_ssl currently imports the crt/key files into
an internal store when the server starts. This way each connection does not
have to read the key/crt from disk, but it already exists in memory. Also,
if a passphrase is required to get the key from the keyfile, the user can be
prompted because this store is built before Apache disassociates from the

So, to implement this ip-based crt/key file lookup some basic changes to the
way mod_ssl manages crt/keys internally are needed.

First, the crt/key store would have to be a shared memory cache of some sort
which is populated by the children processes as requests come in -- instead
of assembled by the parent on startup. This way the crt/key is read from
disk and parsed on the first incoming connection on that ipaddr and stored
in the cache. Every so often a stat (or every request, you choose) might be
required to check and see if the key file has been updated or been removed.
Also, all keys should be expired on a graceful restart.

Additionally, this dynamic crt/key import would not be able to ask for a
passphrase from the user, so the keys could not be passphrase-encoded. But
remember this is mass virtual hosting, so not being able to type a thousand
passphrases is not going to bother anyone, I don't think. :-)

Seems to me this is quite a bit harder than just expanding a template string
with the ipaddr and tossing it in a structure somewhere. Uh, non-trivial
might be the word.

Ralf, I'd just like to know if my thinking about this whole thing is correct
or way-off.

 - David Harris
   Principal Engineer, DRH Internet Services

View raw message