: Running multiple name-based web applications on a single ip address with SSL I'm working on web projects. My scenario is I have two web applications running on one single web server (Apache).

@Yeniel560

To be able to serve multiple host names on the same machine, you essentially have 3 options:


Use a different IP address per host: presenting one certificate per IP address. (This seems out of the question for you, if you're limited to a single IP address.)
Use Server Name Indication: this will allow you to present a different certificate depending on the host name that is requested. This requires support from the client side; in particular, this will fail on any version of IE on Windows XP (and possibly on some mobile devices).
Use a certificate that is valid for both host names that you're serving. If the host name fall within the same pattern, a certificate with a wildcard name should work (although their use is discouraged); otherwise, you can use a certificate with multiple Subject Alternative Name entries (often referred to as Unified Communications Certificates (UCC) certificates by CAs). In this case, the same certificate could be valid for both abc.com and xyz.com at the same time.

Vote Up Vote Down

@Gloria169

It looks like this is possible, provided all the required pieces of the puzzle are in place.

According to the Tech Republic article Configure Apache to support multiple SSL sites on a single IP address recent versions of Apache and OpenSSL support the SNI (Server Name Indication) extension to the SSL protocol - however you'll need to be happy that your users are also on more modern browsers (as there's no support for this from IE7 on Vista machines, nor from Safari 3.2.1 before OS X 10.5.6 - Chrome and Firefox should be OK these days).

In terms of server-side configuration you need to be running:


Apache 2.2.12 or higher.
OpenSSL 0.9.8f or later and must be built with the TLS extensions option.
Apache must be built against this version of OpenSSL as it will enable SNI support if it detects the right version of OpenSSL — the version of OpenSSL that includes TLS extension support.


You can then configure Apache as follows:

Listen 443
NameVirtualHost *:443
SSLStrictSNIVHostCheck off
<VirtualHost *:443>
DocumentRoot /srv/www/example1.com/
ServerName example1.com ...
</VirtualHost>
<VirtualHost *:443>
DocumentRoot /srv/www/example2.com/
ServerName example2.com ...
</VirtualHost>


This tells Apache to listening to port 443 for virtual host requests on all IPs. The new keyword SSLStrictSNIVHostCheck is disabled, meaning we will not throw a 403 error if the client does not support SNI; instead, they will be redirected to the SSL site defined first (example1.com in the example), so be sure to define your default site first.

You've already ruled out the best option: which is to add a second network adaptor and IP address to the server and bind the second SSL site to that IP address (so you have the standard 1 to 1 mapping of IP and SSL).

A final option that I've seen in the past is to have the SSL certificates reside on a firewall/load-balancer, so the requests are decrypted there, and are then sent unencrypted to the appropriate web server and the response is then encrypted on the way back to the browser - this is effectively putting the firewall as a "man in the middle" proxy, which will may be an issue for your company, and the sort of kit that supports this ("Layer 7" I believe) tended to be fairly expensive - and I believe we had multiple IP addresses on the load-balancer to support this anyway.

One example of a public facing website I worked on had two different CMS systems running in parallel on different servers, but both needed to be able to serve some content under SSL without using a different URL (for logging in, user profiles, etc.) so the load-balancer needed to be able to decrypt the request to work out which CMS to send the request to, and do so.

Vote Up Vote Down