I'm running windows server 2003 sp2 with IIS 6.0.

I only have one ip address (leasing a subnet is really not an option and i'd like to limit my use of the address space anyways), but need to run mutlple single domain ssl enabled sites (wildcards won't work).


Is there not a way using host headers? and keeping the standard port (443)?

all the documentation i've found only really fits for a single organization running multiple subdomains on a shared ip. (one example: http://forums.iis.net/t/1147045.aspx )

we host different organizations and some require ssl, obviously.

any help would be tremendously helpful! thanks in advance for any ideas.

  • 1
    the reason it needs multiple ips is that it binds the current port 443 to the given ip, in other words you can only have 1 domain per 443 binded port... So your short answer is NO, there is no way to setup multiple SSL for multiple domains names with a single ip on the same port 443 to all of them. – Prix Sep 21 '10 at 2:54
  • 1
    Now a work-around for you problem would be to use your IIS as a internal service having multiple internal ips and a external server as a proxy to redirect the calls to your internal service which would in theroy solve your problem. – Prix Sep 21 '10 at 2:57
  • @Prix Thanks for your insightful comments! These really did help me refine my search, as did Dave Holland. – calweb Sep 21 '10 at 14:42
  • i'd upvote you, but don't know how as a comment. – calweb Sep 21 '10 at 14:54
  • That is ok, it wasnt meant as a answer anyway – Prix Sep 22 '10 at 4:18

I don't think you can do this with IIS but it's possible with Apache using SNI (Server Name Indication extension in SSL protocol Configure Apache to support multiple SSL sites on a single IP address.

The problems are on the client side: it doesn't work with IE below 7 and doensn't work on XP, even with IE 7. Vista from IE 7 is ok. No idea if it works with IE 8 on XP. The other big browsers are OK: Firefox (since 2.0), Opera, Safari and Chrome.

Edit: specified browser problem:
IE 7 on XP (and 8 - just tested) will reach the right site but using the default SSL certificates so needing an exception to work with SSL.

Edit: This works with multiple domains (like www.example.com and abc.testing.com)

Edit: added link Apache Doc

  • @Prix, I don't understand your comment and your downvote as I warned about implications that IE/XP combination will only access the 1st defined site using the right digital cert. so the safe exit is here. If OP can't have this restriction he won't use it but all other major browsers work (on XP too) and IE works since Vista. If OP has some control over the users on the 2nd and 3rd site, he can use it perfectly. Anyways this is documented in Apache's Docs: http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI). I use this without problems and my 2nd site is a Plone extranet. – laurent Sep 21 '10 at 14:15
  • rpnet thanks for the suggestion. Apache (or LAMP) wouldn't be an option for us, unfortunately because we're migrating some legacy asp/vbscript apps and many of the site visitors ~20% + use older browsers. – calweb Sep 21 '10 at 14:47
  • I wish/hope this is a path IIS is taking alongside apache...here's a quote regarding my same sentiment: We need SNI not because we have clients connecting with SSL but because we have to host almost a thousand unique webservers (SOAP XML HL7v3 services) with their own FQDN and SSL certificate on a win2008 IIS7 server for incoming SSL connections from other servers. Without SNI this means we need a unique IP-adress per FQDN/SSL-cert, with SNI we could host all the sites on 1 IP. Its obvious that 1 IP-adress for incoming SSL services is lot more efficient/easier to maintain/configure. – calweb Sep 21 '10 at 14:52
  • here's the thread where i lifted that above text: forums.iis.net/t/1161905.aspx – calweb Sep 21 '10 at 14:52
  • @calweb, Yes, I hope this will be done in IIS. Probably when most of the installed clients will support it. Anyways, XP is in end of life and since Vista all reasonably updated browsers work so it shouldn't take SO long. – laurent Sep 21 '10 at 20:30

Calweb, The only SSL by host headers available are wildcard certificates, and even then as you alluded to in your post they only work for single domains with multiple A records. The only option I can see is something Prix was mentioning, putting a server (or a load balancer) out front with the external IP address. The server or the loadbal would be doing it's own host header scrape, figuring out which internal IP that belongs to and passing it to the right place.

  • 1
    Appreciate the answer! If we had more high traffic sites, and more strict requirements, I think we'd consider putting out a reverse proxy. realizing our relatively small shop and the overhead in managing a proxy server, we probably will not go that route however. – calweb Sep 21 '10 at 14:44

Thanks all for the answers and for helping me try to figure this out.

I think the way we're going to go (since there's really no other option given the requirements), is to use a UCC SSL cert with Subject Alternative Names. https://www.digicert.com/subject-alternative-name.htm

It seems that the different root domains don't have to be related www.example.com, www.example.net, but can be www.example.com, www.website.com, www.monkey.com

The idea for a reverse proxy was great, but would have been too much of a task with our budget and time constraints.

  • @calweb I'm trying the same solution and I got some push back from the people in charge of the server, what was you experience implementing this? – MexicanHacker Sep 29 '10 at 19:21
  • well, pretty soon...all the subnets will become even more pricy to lease.....at least for ipv4... – calweb Nov 15 '10 at 20:23
  • so far, so good. not trying to plug digicert, but their support team is top notch in helping you get things right. as for a solution for this on a larger scale shopping cart, i wouldn't recommend because it would be hard to have downtime in those situations when you need to add a subject alternative name. – calweb Nov 15 '10 at 20:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy