HTTPS Web Sites: Just One Per IP?

by Andrew Barber 14. December 2009 07:06

I came across a post the other day where someone stated a misconception; That you can only host one HTTPS web site per IP address available on a server. I think most fairly experienced web server admins know that this is not actually the case, and also know why the misconception came to be. Most web server documentation I've seen tells one how to exceed that false limit, but of course it does not say so in exactly so many words!

Like pretty much everyone else who was ever a teenager, when someone says, "you can't do this", I want to know why. And I want to know why for the same reason I wanted to know why, as a teenager, I could not stay out past X time: so I can find a way around it. The long-and-short of the story is this: The actual limit for HTTPS sites is one per TCP socket, not IP Address. So, for every combination of IP address and TCP port, an HTTPS site can be hosted. Note that Host Headers have nothing to do with this. However; For a number of public uses of HTTPS sites, varying the standard TCP port is not a good option here, meaning the "one HTTPS site per IP" is still an effective standard.

Why, Oh Why?

This is not a primer on HTTP, so you should already know that a single server can serve theoretically thousands of web sites on a single IP address by use of the Host header of the HTTP request. An extremely simplistic HTTP request might look like this:

	GET /index.html HTTP/1.1
	Host: www.example.com
	

The web server actually examines the Host header before the GET (or POST, PUT, TRACE, etc), so that it knows which web site should respond. In this way, multiple web sites can be configured to 'listen' to the same IP/Port combination.

However, this does not work for HTTPS web sites, and why is simple: The entire contents of the HTTP request is encrypted, and it cannot be decrypted until the web server decides which web site should accept that request. The SSL/TLS certificate is tied to the web site in question, so only the correct web site is capable of decrypting that request. That is, after all, the very purpose of the HTTPS protocol! Expecting the Host header to help here invites shades of Catch-22!

What Can You Do?

To have multiple HTTPS sites on a single IP address, you must assign each HTTPS site its own, unique IP/TCP Port combination. So if your server has only one IP, you would use that IP, and assign a unique TCP Port for each such site. Of course, since you are using non-standard ports, you must assure that firewall policies will permit access to these custom ports.

Generally, I do not recommend the workaround I am about to detail, as it is likely to cause confusion at some point. But if you know what you are doing and what the effects will be, it's an option. My primary use of this is to create HTTPS access to private, administrative sites - not for sites that should be accessed directly by normal (i.e. public) readers of a web site.

The reason is this involves having an HTTPS site listen on an alternate TCP port from its default of 443. As you should know, when you type https://www.amazon.com in your browser, TCP Port 443 is assumed (just as TCP 80 is assumed when using regular HTTP URLs). Changing the port, then, requires that the URL to visit a site have the custom port contained in it: https://www.somesite.com:7584 If someone types in your site's HTTPS URL, but leaves out the custom TCP Port, they will end up at what ever site you have on the default port - not good! They will also likely get a warning about how the certificate in question is for site X, but they are visiting site Y. Again, not good!

This is why I do not recommend using this except for administrative access sites, or sites where the only legitimate links in should come from an application - where it is essentially invalid to begin with for a user ever to enter their own URL manually. In those cases, I also recommend not hosting any site on the standard HTTPS port 443, as the resulting error messages from failing to specify the TCP port may invite more confusion than the general 'site not found' that would result if there was no site listening on 443.

Comments are closed
Disclaimer
The opinions expressed herein are my own personal opinions and do not represent those of my partners, clients or contractors in any way.

© Copyright 2014 AndrewBarber.com