One IP, multiple sites and SSL certificates. Using ports ok?

[paul1001]

I am using Windows 2003, IIS6, ASP.NET, Forms authentication with cookies.

I want to develop multiple websites where each website requires some pages to use SSL. I have one physical server with one IP address. I don't want to buy more IP's. Many people say you need to buy an IP for each site requiring SSL. I understand this because the host header is encrypted with SSL. But as I understand SSL, it works with the IP/port combination.

This is what I visualize: abc.com and xyz.com both share same IP. The unsecure content for both sites uses port 80. No problem so far. Then abc.com is assigned port 44443 (or whatever is available) for SSL. Specific pages in abc.com are designated on the server to use only https, ie login.aspx. Then xyz.com is assigned port 44444 (or whatever is available) for SSL. Specific pages in xyc.com are designated on the server to use only https, ie login.aspx. A user goes to http://www.abc.com, clicks on link to a page that requires SSL, they are directed by the code to https://www.abc.com:44443/login.aspx. The SSL certificate for abc.com works because the correct port was used.

(I'd like to know if there is anyone out there using ports as a workaround to buying an IP for each website that requires some pages to be secure. What are the problems with this approach?)

I know of one problem: Continuing with the example above, if the user changes just the URL's port to 44444 and then the user clicks GO, then the website shown will be that of xyz even though abc is in the url. The browser will also show a warning concerning the SSL certificate. Admittedly this is alarming to the user should he do this.

Please respond with your opinion, experience, and knowledge.

Thanks

Paul

[DMacedo]

You cannot use the same IP/port combination for SSL hosts.
Sadly, there is no workaround.

Websites are distinguished by hostname, rather than IP address.
The hostname of the requested site is passed in the 'Host:' header field in the HTTP request. The server uses this header field to determine the virtual host.

Now when you enable SSL, the entire HTTP request is encrypted, including this host header.
To decrypt the request, the server needs to access the correct SSL key, and if it were configured to host several SSL sites on the same IP/port combination, it would not be able to determine the virtual host.

So the server needs the host header to select key, but cannot read the host header until it's decrypted...

Therefore, each SSL enabled virtual host must have a unique IP/port combination. So you have to change the IP/port combination either by changing the port or buying IP addresses.

Another, more expensive (but reliable) alternative is to have a wildcard ssl and offer sub-domains that share the same SSL certificate, in this situation you do not have to buy additional IP addresses (but have to pay a lot for these certificates)!

Damn you made me type!

Hope that clears your questions,
BTW, welcome to SitePoint Forums!

[paul1001]

Thank you for your reply. Sorry about all the typing. So you do confirm that it is an IP/port combination. That's what I was trying to state in my original post.
Is anyone out there doing it (one IP, multiple sites, each site has own ssl certificate, each site has some pages requiring ssl, each site has a unique port for those pages requiring ssl)?
I think the IP/Port combo works with SSL (except for the problem I showed in the original post). I want to know if anyone IS DOING this. I never see other sites showing the port in their urls for pages they secure. Are there any security problems?

I don't want to do the wildcard SSL because it applies to one domain and its subdomains. When someone goes to abc.com, I'd like them to see abc.com not abc.mywebhostdomain.com.

Picky, picky, picky.

[DMacedo]

No one wants to use non standard ports, even if they do, that's not a solid image for your customers.
And I'm sure some people don't mind using non-branded SSL certificates!

But your best option is to order additional IP addresses, and SSL websites is a valid justification on ARIN/RIPE/LATNIC (not sure about asia, but should be the same), so is the question of paying an extra $1-10 monthly for the extra IP?

[paul1001]

Thanks. Yes, it is the extra $10 a month. I work for a start-up company that's 2 years old. Earnings are slim. We host about 20 non-secure sites. We just signed on a bunch of clients that want secure pages on their sites. Because I didn't do my homework on SSL, we under-quoted prices to them. Looks like I'll be buying some IP's and our clients will be getting great deals.

Live and learn.

Once again. Thanks for you posts.

[DMacedo]

For my extensive (3 year+) experience with web hosting: don't live from bad earnings.

It's better to provide a quality service for $50 a month than have those issues with customers paying $10 ... And you shouldn't move into a new venture without a detailed business plan, then these mistakes pop all along

My advice is that you should (somewhat) explain the costs to your customers and charge what is necessary to at least break even.

You're welcome