If multiple hostnames are hosted on the same IP, it's not straight forward to allow them to support https. What are the best options in terms of browser support and/or web server support?

5 Answers 5


From what I've seen "Server Name Indication" is the main way to achieve this at the moment.

One of the downsides is that older browsers won't support this so depending on the site it may not be a possibility for it to be used.

Edit: Just to update following @D.W.'s and @Piskvor's comments looks like there's a list of supported and unsupported browsers on the linked Wikipedia page now.

All popular browsers support SNI, including all versions of Internet Explorer on Windows Vista and later. Internet Explorer 6, 7, and 8 on Windows XP were the main browsers that did not support SNI, but they no longer receive security updates since April 2014.


There are two ways: either all the sites use the same certificate (in which case you need a way to make the client browser accept the certificate regardless of which site the client intended to contact), or you select the correct certificate depending on the site which the client wants to connect to (in which case you have to obtain that information some way or another).

For the first way, consider RFC 2818, which specifies what the browser actually expects from the server certificate. The browser wants to connect to a URL, which includes a server name part (after the https:// but before the next /); the browser wants to find that name in the server certificate. The details are in section 3.1. Basically, the Subject Alt Name extension in the certificate is scanned for names of type dNSName, and one of them must match the server name in the URL. If the Subject Alt Name extension contains no dNSName at all, of if there is no Subject Alt Name extension in the server certificate, then the Common Name in the subjectDN is used. The wildcard character "*" can be used to match "any" name part, but this is not reliably supported by every browser.

Therefore, to support multiple sites on the same IP and port, use a certificate which lists all the site names in a Subject Alt Name extension. This has a few drawbacks, e.g. it reveals all the site names (one simply has to connect and look at the certificate); also, you need to get a new certificate every time you add a new site. Finally, your certificate provider might make things a bit more difficult or expensive (e.g. the free certificates from StartSSL are single-domain only; to get a certificate with multiple domains, you must pay).

The second way involves the Server Name Indication, which is an extension to SSL. When using this extension, the client announces the intended server name early enough in the handshake, so that the server can choose which certificate to use depending on what site the client wants to talk to. Unfortunately, support for SNI is not available with Internet Explorer on Windows XP, a still common combination (according to StatCounter global stats, as of October 2012, there are still more than 12% of Web users who use IE 8.0, presumably many of them on WinXP -- note that since the WinXP share is 27% of the OS, one can conclude that more than half of the WinXP users have switched to a non-IE browser). Ditching 12% of the potential site audience is a non-trivial policy decision.

Also, with SNI, the server software must support it, and be configured to use it. See this page for how to do it with Apache and mod_ssl.

  • Since you posted this answer, how has the usage share of Windows XP and Internet Explorer on Windows XP changed? Feb 14, 2016 at 22:06

Another option is to use a wildcard SSL certificate if your host names allow it.
So you'll have a certificate with CN=*.yourdomain.com covering www.yourdomain.com, mail.yourdomain.com, ftp.yourdomain.com and so on.

  • Not a great idea, though probably the easiest... There are numerous security issues with wildcard SSL certs.
    – AviD
    Nov 12, 2010 at 13:07
  • @AviD: I definitely agree that's not a very good idea from a security standpoint (not to mention they're pretty expensive too - if I remember correctly), just wanted to list all possible choices. If you have a good link explaining the risks I'll add than to the answer. Nov 12, 2010 at 16:35
  • oo, haven't messed around with wildcard certs in a couple years... so no link handy, sorry. But considering this is a security site, I don't think we should be listing "possible choice" that are not recommended... :)
    – AviD
    Nov 13, 2010 at 16:05
  • 1
    @AviD I'm also interested in knowing the security risks with wildcard certs. Shall I add a separate question? Oct 10, 2011 at 15:13

As far as I know, for most web servers, if you have to have different host names and they must be on the same IP (better to go for virtual IPs, but lets leave that), you will need to use different ports.
E.g. 443, 444, 445, etc.

Not always so intuitive for the user, though...

  • Depending on your webserver, Server Name Indication would be a better choice as @Rory said. However, if your webserver does not support that, then its ports for you.
    – AviD
    Nov 11, 2010 at 22:49

You may want to consider Subject Alternative Names, since they are more flexible than Server Name Indication (and may work in older browsers!). SAN's allow a single certificate to be used for up to 25 DNS names or more depending on who you purchase your SAN from. Each domain can have a different TLD (top level domain) such as .com, .org, etc.

Wildcard certificates might work too but they have to have a common top two elements (*.example.com). However you're likely to lose most of your vendor's e-commerce insurance with these class of certs; and I don't think it's possible to get an EV cert of this type.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .