Virtual hosts and SSL
Asaf B.
Environment: Linux RedHat 9.0 - httpd-2.0-40
I have an httpd.conf with several vhosts, each one refers to a
different port and has a different DoucumentRoot.
I want to enable SSL, therefore I need to define ssl.conf.
How do I define ssl.conf in a way that each port in the httpd.conf
will refer to different SSL port and both will have the same
DocumentRoot?
I know vhosts can be defined in the ssl.conf too, but I didn't
understood how I link a port in the httpd.conf to a port in the
ssl.conf?
currently there is only one ssl port (the default 443) and therefore
no matter what port I work on, when I send an https request, I will
always go through it.
For example, if I have the following vhost:
##################
Listen 1111
NameVirtualHost my_comp:1111
<VirtualHost my_comp:1111>
DocumentRoot /var/www/location1111
</VirtualHost>
##################
I would like that when I send an https request, to get to the same
document root above and not to the default DocumentRoot defined in the
ssl.con for port 443 (I want to leave that for ports other than 1111).
What do I need to do in the ssl.conf?
Thanks
Randell D.
news:9debd2d1.03090...@posting.google.com...
I don't think you can (or perhaps I misunderstand your question) The
following is an extract from the apache docs page at
http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#vhosts
Q: Why can't I use SSL with name-based/non-IP-based virtual hosts?
The reason is very technical. Actually it's some sort of a chicken and egg
problem: The SSL protocol layer stays below the HTTP protocol layer and
encapsulates HTTP. When an SSL connection (HTTPS) is established
Apache/mod_ssl has to negotiate the SSL protocol parameters with the client.
For this mod_ssl has to consult the configuration of the virtual server (for
instance it has to look for the cipher suite, the server certificate, etc.).
But in order to dispatch to the correct virtual server Apache has to know
the Host HTTP header field. For this the HTTP request header has to be read.
This cannot be done before the SSL handshake is finished. But the
information is already needed at the SSL handshake phase. Bingo!
Why is it not possible to use Name-Based Virtual Hosting to identify
different SSL virtual hosts?
Name-Based Virtual Hosting is a very popular method of identifying different
virtual hosts. It allows you to use the same IP address and the same port
number for many different sites. When people move on to SSL, it seems
natural to assume that the same method can be used to have lots of different
SSL virtual hosts on the same server.
It comes as rather a shock to learn that it is impossible.
The reason is that the SSL protocol is a separate layer which encapsulates
the HTTP protocol. So the problem is that the SSL session is a separate
transaction that takes place before the HTTP session even starts. Therefore
all the server receives is an SSL request on IP address X and port Y
(usually 443). Since the SSL request does not contain any Host: field, the
server has no way to decide which SSL virtual host to use. Usually, it will
just use the first one it finds that matches the port and IP address.
You can, of course, use Name-Based Virtual Hosting to identify many non-SSL
virtual hosts (all on port 80, for example) and then you can have no more
than 1 SSL virtual host (on port 443). But if you do this, you must make
sure to put the non-SSL port number on the NameVirtualHost directive, e.g.
NameVirtualHost 192.168.1.1:80
Other workaround solutions are:
Use separate IP addresses for different SSL hosts. Use different port
numbers for different SSL hosts.
Paul Rubin
It could be put into Apache and Mozilla pretty straightforwardly.
Maybe other browser implementers would follow.