Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
add comment

5 Answers

up vote 15 down vote accepted

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.

IE6 is the main browser that does not support SNI. All other popular browsers that I know of, do support SNI except:

IE8 on WinXP is quite popular, yet SNI is only supported in IE7 or above, on Windows Vista or above. Apparently it's not possible to do SNI in IE on WinXP at all.

share|improve this answer
add comment

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.

share|improve this answer
    
Not a great idea, though probably the easiest... There are numerous security issues with wildcard SSL certs. –  AviD Nov 12 '10 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. –  Eugen Constantin Dinca Nov 12 '10 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 '10 at 16:05
    
@AviD I'm also interested in knowing the security risks with wildcard certs. Shall I add a separate question? –  Krzysztof Kotowicz Oct 10 '11 at 15:13
add comment

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...

share|improve this answer
    
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 '10 at 22:49
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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