We have the following scenario in testing SNI on Windows Server 2012 R2 with IIS 8. Domain names and IP addresses listed below are fake and for example only.

WEB SITE NAME      IP ADDRESS     Host Name/Header (SNI)   Certificate Domain
x.domain.com      x.domain.com             x.domain.com
y.domain.com      y.domain.com             y.domain.com

When only 'x.domain.com' and 'y.domain.com' are configured using SNI with their own certificates on the same IP address, both sites work fine in all browsers, but when you select either of the sites, IIS shows displays a message stating "No default SSL site has been created. To support browsers without SNI capabilities, it is recommended to create a default SSL site".

SNI Error

If I create a default SSL site (a site on the same IP address using HTTPS but with no host name/SNI) it breaks the certificates on the other SNI sites on the same IP address. If I add the default SSL site like the following

WEB SITE NAME      IP ADDRESS     Host Name/Header (SNI)   Certificate Domain
somedomain.com      NULL                     somedomain.com

Once that exists (it doesn't matter what certificate I use), the other SNI domains on that IP address generate a certificate error as IIS is apparently feeding the users the certificate for the default SSL site instead of the certificate specified for the site in IIS.

Can anyone please shed some light on how to properly configure the default SSL site in IIS?

  • 1
    It would be really beneficial if the reason for the downvote was recorded so that the question could be clarified.
    – Beems
    Mar 11, 2016 at 18:39
  • This is actually a very good question. In my case I had all my site bindings set to "All Unassigned" and the NULL host name biding set to an IP address. The SNI was not working because of that extra biding. The solution was to change the extra binding from IP to "All Unassigned".
    – clns
    Mar 14, 2017 at 6:37

1 Answer 1


I think if you change the IP address for the somedomain.com binding to "All unassigned" rather than, it will stop getting in the way of your SNI sites [surprisingly].

  • 2
    This hack worked for me, but it's very poor behavior on IIS's part. It should be trying to use the SNI binding first when the client provides an SNI host name, not a specific IP/port binding. And this workaround is not intuitive at all. Aug 31, 2017 at 12:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .