Home / server / Questions / 104669
In Process
TrojanName
Asked: 2010-01-21 08:42:21 +0800 CST

Combining 3 different websites under 1 SSL cert?

  • 772

I should preface this by saying I have zero practical knowledge of SSL, and this particular setup seems especially complex. I have a situation as follows: I'm running 3 websites for a client, a copy of each on 2 Linux boxes. The client is running a hardware load balancer between their firewall and the 2 boxes to distribute the traffic between the 2 boxes. Currently, the websites are all on HTTP only, each site has its own IP address on each box and it available on a public url like a.mysite.com, b.mysite.com and c.mysite.com

The client has asked me to switch everything to run under HTTPS and also to try to configure the following setup: create a new domain (under https) https://main.mysite.com with https://main.mysite.com/a/ mappng to a.mysite.com, https://main.mysite.com/b/ mappng to b.mysite.com etc

The primary goal is to switch all 3 sites to HTTPS. The unified under 1 domain thing is a "nice to have". The client has this belief that certificates are expensive, are they?

First of all, I know nothing about buying certificates, setting up SSL etc, so any links to a beginners guide to HTTPS would be greatly appreciated. A rough idea of cert prices would be nice too.

Second, because the webserver software needs a recompile to run under SSL, I'm interested in solutions to this that allow me not to change the webserver software. Would this be a reverse proxy?

Third, is the "unified under 1 domain thing" even possible?

Fourth, how many SSL certs do I need in this case?

cheers!

https

3 Answers

  1. A Multiple Domain (UCC) SSL certificate is cheaper than the Wildcard SSL often suggested. It only works for 5 domain variations instead of an infinite number that the Wildcard offers but it may be worth considering if your needs are simple.

    Either way a Single SSL cert can handle your needs. Only the price and future flexibility differ.

    • 2

  2. Certificates can be as expensive or as cheap as you want them to be. What you likely want is a 'wildcard' certificate, which will allow *.mysite.com to be allowed. Wildcard certs won't be as cheap as single-site certs, but eventually they become cheaper than many single-site ones. You can also get multiple names on a single cert, but this is a one-time thing, where a wildcard cert will allow any name under that common domain root.

    You aren't saying which server software you are using. If Apache, which I assume from the "recompile" mention, and you are running it on some form of Unix, try this command:

    httpd -t -D DUMP_MODULES | grep -i ssl

    If you get back anything saying ssl is there, well, it's there.

    If it isn't, it may be able to be dynamically loaded. However, most distributions and package systems are likely to install ssl by default. It's just that common.

    I'd also check to see how old your server software is. I get not wanting to change things much, but I think you'll be happier without a reverse proxy to add to the maintenance of this site.

    • 1

  3. I would think you could satisfy this with either a wildcard certificate (expensive):

    • *.mysite.com

    Or three certificates (not as expensive):

    • main.mysite.com
    • a.mysite.com
    • b.mysite.com

    You should also be able to create a url rewriting rule on the main site to send clients to the correct domain:

    This design wouldn't require a change to your server deployment, rather just adding a certificate to each site along with a url rewrite rule on your main site.

    And, don't forget to add the redirect url for remapping from http to https:

    • 0