A Day in the Life of #Apache
Running Name-Based SSL Virtual Hosts in Apache
by Rich Bowen, coauthor of
Apache Cookbook02/17/2005
Editor's note: After a winter hiatus, Rich Bowen is back with another column based on his conversations on the IRC channel #apache. This week Rich tackles SSL virtual hosts--if you think it's not possible to run them in Apache, think again. Rich is a coauthor of O'Reilly's Apache Cookbook.
#apache is an IRC channel that runs on the irc.freenode.net IRC
network. To join this channel, you need to install an IRC client (XChat, MIRC,
and bitchx are popular clients) and enter the following commands:
/server
irc.freenode.net
/join #apacheDay Ten
In this week's article, I might seem to contradict myself, so it's important that you read the whole piece. If you stop too soon, you might not get the whole picture.
Over the last few months, I've seen a big increase in questions regarding SSL
and name-based virtual hosts (vhosts). The official answer on this topic is that you
can't do that. Or, to quote fajita:
<DrBacchus> ssl vhosts
<fajita> When using SSL, each virtual host must have either its own IP address or its own port. Or both. or for details see http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#vhosts2
It's important to explain here that this is a limitation of SSL, not a limitation of Apache. That is, it's not that the Apache programmers were just so lazy that they never got around to this, but that SSL itself makes it impossible.
The reason that it's impossible lies in the way that SSL works. To grossly oversimplify, when a browser makes an SSL request (i.e., any URL starting with "https://"), the server sends the SSL certificate before it pays any attention to which URL you're requesting. Consequently, if you have multiple virtual hosts on that one IP address, you'll still always get the same certificate, which, in most cases, will not be the right one for the virtual host you requested. And when that happens, the browser pops up a scary warning message saying that the certificate does not match the web site you wanted to view.
Figure 1. SSL warning
There are several different possible solutions to this problem, but not all of them are acceptable to everyone.
The "right" thing to do is to run the other SSL site on another IP address. However, very few of us have access to an unlimited supply of IP addresses.
The "almost right" thing to do, failing that, is to run the other SSL site on
the same IP address, but using a different port. The problem with this method is that
users of the site will have to explicitly specify the port number in the URL, in
order to connect to the right site. For example, they might have to access
https://www.example.com:445/ in order to access a site running on port 445.
Since 443 is the default port for https connections, it doesn't need to be
specified in the URL. This approach may be acceptable to many people,
particularly given that most SSL sites are arrived at via links (or redirects)
from other sites, rather than directly by the user typing in URLs.
<VirtualHost _default_:443>
ServerName www.domain.com
SSLEngine on
SSLCertificateFile /path/to/www.domain.com.cert
SSLCertificateKeyFile /path/to/www.domain.com.key
DocumentRoot /www/vhosts/domain.com
</VirtualHost>
<VirtualHost _default_:444>
ServerName www.domain.org
SSLEngine on
SSLCertificateFile /path/to/www.domain.org.cert
SSLCertificateKeyFile /path/to/www.domain.org.key
DocumentRoot /www/vhosts/domain.org
</VirtualHost>
|
|
Related Reading 
Apache Cookbook |
Notice that the two virtual hosts have different certificates specified, so that you get both authentication and encryption.
However, a great many people want to have multiple name-based virtual SSL hosts on the same port and same IP address. They're OK with the fact that the users will get a warning message every time they use the site. At this point, we let them in on a little secret. It is in fact possible to run name-based SSL virtual hosts. Sort of.
There are two aspects to SSL. The one that most people tend to think about is encryption. That is, all data to an SSL site is encrypted, and cannot be deciphered by a third party intercepting the data in the middle. The other one is authentication. That is, is the data you're receiving really coming from the host that you requested it from? When you pay for your SSL certificate, it is the authentication bit that you're paying for. You're paying for that company to verify that you are legally entitled to use that URL and the name under which the certificate will be signed. That way, when you connect to your bank, you can look at the certificate and be assured that you are indeed connecting to your bank, and not to some teenager scamming your money from his mother's basement.
When you run multiple SSL sites from a single certificate, you have the same level of encryption that you would have on any "correctly configured" SSL site. However, you completely forfeit any authentication ordinarily offered by SSL.
Stated differently, each time you connect to an SSL site, in addition to providing encryption, the browser checks to see that the certificate you are using is the "right" one. That is, that the web site name listed on the certificate is exactly the same web site to which you're connecting. If it's not, that's when you get the warning message. If you're getting the "wrong" certificate (that is, the certificate and the web site don't match) then there's a chance, although a very small one, that someone has intercepted your communication, and you're not actually talking to who you thought you were.
Assuming you followed that, we'll go on. If you didn't, read it again. It's a very important point.
The configuration examples following use the mod_ssl module. If you're using
the apache-ssl implementation of SSL, the concept is the same, but the
configuration will look somewhat different.
If you're persuaded that you want to run multiple SSL virtual hosts on the same IP address and port, this would be accomplished much like regular name-based virtual hosts, as follows:
NameVirtualHost *:443
<VirtualHost *:443>
ServerName www.domain.com
SSLEngine on
SSLCertificateFile /path/to/www.domain.com.cert
SSLCertificateKeyFile /path/to/www.domain.com.key
DocumentRoot /www/vhosts/domain.com
</VirtualHost>
<VirtualHost *:443>
ServerName www.domain.org
SSLEngine on
SSLCertificateFile /path/to/www.domain.com.cert
SSLCertificateKeyFile /path/to/www.domain.com.key
DocumentRoot /www/vhosts/domain.org
</VirtualHost>
|
In other words, exactly the way you'd set up regular virtual hosts, except turning on SSL in each one.
You'll note in the above example that the same certificate file is specified
for both vhosts. This doesn't really matter, since you'll always get the same
certificate anyway. However, if you fail to set the certificate in one of the
vhosts, your server may fail to start, complaining that you didn't specify a
certificate file. Setting the same cert file in both places is the easiest way
around this.
Just so this is perfectly clear, you will get the warning message when you
access one of those vhosts--all of them that don't match the certificate,
specifically. That is the price you pay for this functionality.
One final comment. Yes, this is annoying. And, yes, everyone is aware that it's annoying. Very smart people are actively working on a solution. The solution is called TLS upgrade. This is not the place to go into the technical details of how that works. But you should encourage your favorite browser vendor to implement this feature in future versions of their software.
See you on #apache.
Rich Bowen is a member of the Apache Software Foundation, working primarily on the documentation for the Apache Web Server. DrBacchus, Rich's handle on IRC, can be found on the web at www.drbacchus.com/journal.
Return to the Apache DevCenter.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 17 of 17.
-
Multi Domain Certs
2009-05-14 09:48:44 R Kraft [Reply | View]
The name based virtual host solution works great with multi-domain certs (UUC). No warnings.
-
one ip virtual hosts
2009-03-21 02:34:58 rustek [Reply | View]
I have a fairly simple solution to hosting several secure hosts on one ip address without having to enter the port number in the address.
see http://wesayso.net
-
Seperate IP addresses and NAT
2009-02-05 12:02:56 bradcan [Reply | View]
This works behind an Ipcop firewall. I've yet to discover if Apache will support separate certificates like this.
-
Multiple SSL Virtual hosts on same IPA
2007-04-03 14:47:03 rspence33 [Reply | View]
This will prolly be a lame question - but I'm not finding success in trying this. I have 1 IP and want to run 2 SSL-enabled apache instances on the server on different ports. I have separated the files for the 2 instances into 2 diff directories - Docroot, start scripts, etc..So I have 2 httpd.conf & ssl.conf files. How can I set up these 2 SSL instances? If anyone can simply send the VirtualHost snippets that would be fantastic.
Thanks very much,
Ray Spence
-
Named VHosts and SSL with SSL Server
2007-02-20 11:21:25 lemark [Reply | View]
You mention the following solution: The "right" thing to do is to run the other SSL site on another IP address. However, very few of us have access to an unlimited supply of IP addresses.
However, I have been unable to find documentation on how to implement that solution anywhere. Can you provide a pointer to this information?
-
Mixed name, port, and ip-based virtual hosts
2007-02-12 12:51:20 Chris9 [Reply | View]
Hello Rich, I've read a number of your postings on this topic already and they have proved helpful so far. Thanks! OK so here's my question. I have a server with about 10 name based virtual hosts. I now need to set up 2 of them with separate SSL certificates. I understand that these need either a different IP or a different port. The different IP seems easier. BUT I am concerned that it is having problems because we are using NAT, so that within the apache config, the address is an internal one (e.g. 192.168.1.7 I've created another one on that same server as 192.168.1.107) Both of these IP address seems to be recognized fine within the network. Will this work as far as the virtual host setup, or do I need to have different external IP addresses too. I can't seem to get the secondary IP address to work in apache, the site with the secondary IP just goes to the default site.
Any suggestion or guidance would be much appreciated!
-
multiple VHs on SSL?
2006-06-21 12:21:11 jrlooney [Reply | View]
I tried the example above where the ports 443 and 44 4 were specified, but Apache won't start when I do that. I was wondering if someone had successfully done this and would offer to look at the SSL part of my httpd.conf?
thanks in advance
-
Hmm. Perhaps I'm mistaken
2005-02-23 14:56:16 Rich Bowen |
[Reply | View]
I could very well be mistaken. I'll investigate the issue of wildcard certs more thoroughly. I was under the impression that support for them was spotty.
--Rich -
Hmm. Perhaps I'm mistaken
2005-03-04 03:23:47 Rich Bowen |
[Reply | View]
The issue with wildcard SSL certs has always been one of browser support. And, it turns out, I was somewhat misinformed. It appears that all the latest versions of all the major browsers support wilcard certs, with one caveat.
Internet Explorer 6 only recognized one level of naming for the wildcard. That is, *.example.com will match www.example.com, but will not match www.monkeys.example.com
And, of course, if you're not making the certs yourself, wildcard certs are considerably more expensive than regular ones.
Sorry for the misinformation. -
Hmm. Perhaps I'm mistaken
2005-03-04 14:08:54 CraigBuchek [Reply | View]
According to the RFC (2818 section 3.1, 4th paragraph), user agents are not supposed to accept more than 1 level of names.
However, it also says that "more than one dNSName name" may be contained within a certificate, and "a match in any one of the set is considered acceptable". So that would seem to be the proper way to include multiple names in a single SSL certificate. However, I doubt that any browsers support that, or certificate generators for that matter. I could be wrong, but I couldn't find anything in Google on it. -
Hmm. Perhaps I'm mistaken
2005-03-22 13:24:17 Frank-van-Beek [Reply | View]
I might have found a solution.
On this page http://wiki.cacert.org/wiki/VhostTaskForce a couple of solutions are listed.
By combining solutions #2 and #3 I was able to have multiple domains in one certificate. See the combined solution #4 on the same page. It's supported by most mayor browsers.
-
Using SSL Wildcard certificates
2005-02-17 22:26:16 Brice [Reply | View]
Using Wildcard SSL certificate which cover many subdomains (*.mydomain.com) is a good way to avoid browser side warning. But they can't cover same domain names with different tlds (mydomain.org, mydomain.com). -
Using SSL Wildcard certificates
2005-02-18 03:19:38 Rich Bowen |
[Reply | View]
SSL wildcard certificates don't work reliably in all browsers, and so their use is not often encouraged. -
Using SSL Wildcard certificates
2005-02-23 14:45:35 davidengel [Reply | View]
We have been using wildcard certificates for the past year+ with no problems. It greatly reduced our cost for certificates and has made management of the certificates easier. I have yet to see a browser that did not support it.
