Enabling SSL for Apache2

Apache2 and SSL

The problem with SSL and Virtual Hosting

To enable SSL for Apache2, you must first realise some important limitations. This section is meant to outline these limitations. First off: let's look at simple HTTP traffic, something that has nothing to do with SSL - but bear with me.

One Apache instance can run multiple websites on one server (one IP address), as so-called virtual hosts. First off, let's assume we have one single server, serving two websites. These can be found using two different DNS names, e.g. www.saruman.biz and www.iceditch.nl. Now suppose a visitor wants to visit one of these sites. The visitor types in a URI pertaining to any one of the websites (containing the DNS name www.saruman.biz or www.iceditch.nl). In both cases he gets the same IP number (212.238.151.172), so his browser sends the HTTP request there, on port 80. Apache receives the request, looks in it, notices the actual URI in it (say: http://www.iceditch.nl/index.htm or http://www.saruman.biz/wiki/index.php/Main_Page), and directs the request to the right website, the right virtual host. So far, no problem at all.

Now consider what happens if we introduce SSL: any request to the HTTPS-port of the server (port 443) gets encrypted using the public SSL-certificate of the server. However, before using it, this certificate is investigated by the browser of the visitor - one of the (sets of) things that must match, is the common name of the certificate (which must match the DNS-name of the website the visitor is visiting). Thus, a visitor for https://www.saruman.biz expects the SSL certificate to be in the name of www.saruman.biz, and so does his browser. But a visitor for https://www.iceditch.nl expects the certificate to be in the name of www.iceditch.nl. Reasonable, eh? But wait - the single Apache2 webserver can have multiple websites, but only one SSL certificate! And that'll be presented to the visitor at the setup of the HTTPS session, before Apache gets to hear which virtual host the visitor wants to visit.

This means that when multiple virtual hosts on a single Apache2 webserver are "put on SSL", they all share the same SSL certificate. And this means that if we have an SSL certificate for www.saruman.biz, that visitors to the HTTPS-version of www.saruman.biz will be presented the "right" SSL certificate, but visitors to the HTTPS-version of www.iceditch.nl will get a certificate for www.saruman.biz as well - leading to nagging warnings in the browser of each one of your visitors.

In effect, you can run only one virtual host, that's accessible over HTTPS, and gets no raised eyebrows on the certificate name issue. SO! Is this a totally unavoidable problem? For most situations: yes. But in some cases there are workarounds.

A solution for the problem of SSL Certificate names and Virtual Hosting

One workaround would be to have two IP numbers for your server, and have two instances of Apache2 listen on port 443: one instance on the IP of www.saruman.biz, and hosting virtual site www.saruman.biz, and using an SSL certificate for www.saruman.biz. The other instance could then listen on the IP number for www.iceditch.nl and use an SSL certificate signed correspondingly. Simple, effective - but requiring multiple IP numbers, and sort of defeating the reason for having virtual hosting in the first place.

A better workaround is to have all virtual hosts be hosted on URI's that are based on the same toplevel domain, e.g. www.saruman.biz, shop.saruman.biz, webmail.saruman.biz etcetera. When multiple virtual hosts share a common DNS domain, then the (single) SSL certificate for these (multiple) virtual hosts could be based on a wildcard SSL certificate name - in this case *.saruman.biz. The certificate would match all those virtual hosts. Alas, it still wouldn't match www.iceditch.nl...

SSL for your main protected website

First we determine which one of our virtual hosts (assuming you have multiple) we need to provide SSL for. If you have multiple IP numbers for your servers, then you can select the same number of virtual hosts without running into the problems described previously. The only prerequisite for this is, that you've mapped each of those virtual hosts to a different IP number, so that a request to virtual host "one" gets resolved to IP address "one", virtual host "two" to IP address "two" et cetera.

Now we can start by obtaining the necessary SSL certificates.