I'm working on web projects. My scenario is I have two web applications running on one single web server (Apache). Due to my company policy, they ask me to put both of them on SSL (Port #443), no other way round.

Here is where I have a question coming up on my mind. As far as I understand, we can only have one application running over the above mentioned port.

Is there any solution where I can have both of them running over SSL by using only one server? How many possible solutions are there?

What I can think of now is I may assign different domain name for each web application. so, I can achieve that using virtual host setting with Apache. So, both of them can point to my single IP address.


1st web application:   https:www.abc.com
2nd web application:   https:www.xyz.com

Would this be a good idea?

Any advice would be really appreciated.

2 Answers 2


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 www.example1.com
<VirtualHost *:443>
  DocumentRoot /srv/www/example2.com/
  ServerName www.example2.com

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.

  • A second network adapter won't be of any help if there's only one IP address. The certificate on a firewall option is essentially a MITM proxy, which the clients need to be willing to accept (and also can raise its own security concerns).
    – Bruno
    Commented May 15, 2012 at 12:52
  • Yes, although I see that you've also offered this as your first option ;) To be honest, it looks like the either way there are going to have to be some compromises - either more IP addresses, issues with older browsers/OS's or a level of cost and security in the DMZ. Commented May 15, 2012 at 13:08
  • My first option was multiple IP addresses (on the same network adapter or not), not multiple adapters for a single IP address (maybe I misread what you said, that's far more awkward in terms of routing, mostly useful when high redundancy is requires in terms of hardware, but very unusual). Your second option (firewall MITM proxy) is essentially something that re-generates a cert on the fly: it would be OK from within an intranet, but it's not viable for external access, unless you know in advance who your users are.
    – Bruno
    Commented May 15, 2012 at 13:11
  • @Bruno - nope, I didn't mean trying to use the same IP address on different adaptors - I did mean multiple IP addresses. Commented May 15, 2012 at 13:22
  • Ah, sorry, thanks for clarifying. The load balancer (reverse proxy) option works too, but will probably use the same host name. (I'd go for multiple SANs if he can).
    – Bruno
    Commented May 15, 2012 at 13:43

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 www.abc.com and www.xyz.com at the same time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.