Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'd like to host a website that should listen to subdomains (e.g. sub.domain.com) together with multiple websites that live just under a second-level domain (e.g. domain2.com, domain3.com) with IIS and with SSL.

For the website with the subdomains I have a wildcard certificate (*.domain.com) and I also have certificates specifically for the other sites (domain2.com and domain3.com).

Can such a setup be hosted on the same IIS (if that matters, in an Azure Cloud Service web role)?

The issue is exactly what titobf explained here: theoretically for this we'd need bindings using SNI, with the host specified for domain2/3.com and then a catch-all website with * host for *.domain.com. But in practice no matter how the bindings are set up if the catch-all website is on it will also receive all requests to domain2/3.com (although supposedly it's matched only as a last resort).

Any help would be appreciated.

Still unsolved

Unfortunately I wasn't able to solve this: it seems to be solvable only in extremely complicated ways, like creating a software that sits between IIS and the internet (so basically a firewall) and modifies incoming requests (before the SSL handshake takes place!) to allow the scenario. I'm fairly confident this is not possible with IIS, no matter what, not even from a native module.

I have to clarify: we use Azure Cloud Services, so we have a further constraint that we can't use multiple IP addresses (see: http://feedback.azure.com/forums/169386-cloud-services-web-and-worker-role/suggestions/1259311-multiple-ssl-and-domains-to-one-app). If you can point multiple IPs to your server then you don't have this issue since you can create bindings for IPs too, and those will work together wildcard bindings. More specifically, you need an IP for the wildcard site (but since you have a separate IP now you wouldn't have to configure a wildcard host name binding) and another IP for all other non-wildcard ones.

Actually our workaround was the usage of a non-standard SSL port, 8443. So the SNI binding is actually bound to this port, thus it works along with the other bindings. Not nice, but an acceptable workaround for us until you can use multiple IPs for web roles.

share|improve this question
You should absolutely be able to do this on IIS using SNI, without resorting to multiple IPs or non-standard ports. –  Joe Sniderman Sep 14 at 20:12
You mean that IIS should support this? I agree :-). –  Piedone Sep 15 at 11:00

1 Answer 1

IIS does support SNI, even in azure cloud service web roles although you can't get to the config through the portal and if you do it on the box after deployment it'll be wiped with your next deployment. The solution is to automate the config. Have a look here for details:


share|improve this answer
Thanks, but as I explained there is no problem with SNI itself (I'm using it) but rather how wildcard host name matching works in IIS. –  Piedone Oct 2 at 9:43

Your Answer


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.