Single IP and Multiple Wildcard Certificates – Windows 2012 R2

I know that my normal blog posts cover Exchange and Office 365, but I also like to dabble where I can. Today a client of mine was in a bit of a situation. They were moving from a series of physical on premise servers to a single web server in Microsoft Azure, which has a single IP address. The problem was that the original servers had one wildcard cert per server (and by associate, per IP). Now trying to perform the same function, if this were Windows 2008 (R2 too) with IIS 7 it would be impossible, on that one server.
Solution? –> Problem
The solution is to use SNI. However, if not configured properly, SNI will fail. The other issue is that SNI can cause issues with Windows and Older Browsers. The conundrum for the customer was that they needed to support XP and older browsers as well as use SNI to use multiple wildcard certificates on a single IP address. Yes.

The client had attempted to set this up and when browsing to subdomain sites with the second wildcard certificate the browser would display something like this:

When we checked out the certificate, you could see the wildcard certificate was for the wrong domain:
Certificate – *.test.local
Certificate that should have showed up was – *.sub1.test.local

We reviewed the configuration and the correct certificate was assigned.

After a bit of digging and playing with the settings in IIS (again minding the fact that IIS is not my usually playground) and I came up with a solution that would work. The main domain would have a host header assigned and SNI would be unchecked. Then each subdomain site would have SNI checked and a host header used as well. The IP address would be set to unassigned as well. As follows:


I was able to confirm this solution with my lab. Then I had the client replicate this. However they ran into the same issue. We even put SNI on each site. This still failed.
The Fix
So we reviewed each sub-site, each binding and each certificate. All the settings seemed to be in place. However, while reviewing their IS Site configuration I saw they had something I did not:

Correct Sites

Incorrect Sites

Once we deleted the ‘Default Website’ the certificate issues went away. So now we have two wildcard certificates sharing one IP address on a server in Azure.
Conclusion
So the solution, simply outlined, is as follows:

• Install all wildcard certificates.
• Remove the default website.
• For one site (if legacy support needed) IP should be unassigned, Host Header used, correct certificate checked and SNI is unchecked.
• For all other sites – Unassigned IP, Host Header used, SNI check, and correct certificate selected.

That successfully worked for my customer and my test lab I use for validation. Both environments were using Windows Server 2012 R2.