Re: SSL certificates and virtual hosts

[Greg Fennell <fennellgb@xxxxxxxxxxxxx>]

To add to my last response, here is some good reading.

http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts

Why can't I use SSL with name-based/non-IP-based virtual hosts?

The reason is very technical, and a somewhat "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 go to the correct virtual server Apache has to know the Host HTTP header field. To do this, the HTTP request header has to be read. This cannot be done before the SSL handshake is finished, but the information is needed in order to complete 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 SSL session is a separate transaction, that takes place before the HTTP session has begun. The server receives 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, which matches the port and IP address specified.

You can, of course, use Name-Based Virtual Hosting to identify many non-SSL virtual hosts (all on port 80, for example) and then have a single 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 include:

Using separate IP addresses for different SSL hosts. Using different port numbers for different SSL hosts.

On 10/18/2011 9:27 AM, James Moe wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,
  Our website account with our ISP has one fixed IP address and allows
a number of virtual hosts. The main site has an SSL certificate for
secure access. I wish to add another certificate for one of the named
virtual hosts. According to Tech Support the account only allows one
SSL certificate per IP address.
  The secure setup is like this:

Listen 66.84.59.125:443
<VirtualHost 66.84.59.125:443>
  ServerName sohnen-moe.com:443
  ... the usual SSLCertificate* directives to the SSL files ...
</VirtualHost>

  Despite the claim of only one certificate per IP, I tried adding the
following vhost to the configuration file:

NameVirtualHost retailmastery.com:443
<VirtualHost retailmastery.com:443>
    ServerName retailmastery.com:443
    DocumentRoot /home/www/rm1
    SSLEngine on
  ... the usual SSLCertificate* directives to other SSL files ...
</VirtualHost>

  It does not work.
  Is the claim of only one cert per IP address correct? Or have I made
an error in the configuration?

- -- 
James Moe
moe dot james at sohnen-moe dot com
520.743.3936
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6dqQYACgkQzTcr8Prq0ZO9oACfUHAJ34StjeetvPp/B+//6mno
RNoAnRzqGA1wm+dcolxwNw0HvLfqbi8c
=njxM
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
   "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx