I have Site A in IIS 8.0 configured to an SSL certificate with the binding ###.###.###.###:443. I also have Site B configured to a different certificate with the binding ###.###.###.###:443 (same IP but host = sub.domain.com) For the Site B binding, I checked the SNI enabled box so IIS allowed it.

The problem is, I find that loading Site B from an SNI-enabled browser serves the certificate for Site A. I assume this is because the Site A binding is technically satisfied, so IIS stops looking at other bindings to serve the request. (I noticed that the netsh http show sslcert command seems to show the Site A binding first in the display order, although I have no idea if that order is meaningful.)

Is there a way to change the binding order in IIS so that it attempts to bind requests to the Site B SNI-host binding first, and only after that falls back to the Site A non-SNI (IP:port only) binding? (For legacy compatibility, I don't want to enable SNI on the Site A binding.)

  • Have you reviewed this MS article? blogs.msdn.microsoft.com/kaushal/2012/09/04/… – Mass Nerder Apr 11 '16 at 22:47
  • @MassNerder Yup, I didn't see anything in there about changing the binding order. – Jordan Rieger Apr 13 '16 at 19:45
  • The default SSL site and the SNI handshake info at the bottom is no help? – Mass Nerder Apr 13 '16 at 19:55
  • I don't see that message about needing a default SSL site because I have many non-SSI bindings already. The handshake info is interesting but it doesn't address my issue. – Jordan Rieger Apr 13 '16 at 20:22
  • Granted, the article seems to be saying that IIS will look at SSL IP:port bindings first before looking at SNI IP:port:hostname bindings, which I already know. My question is how to fix that. – Jordan Rieger Apr 13 '16 at 20:40

Why not change the certificate used for a single certificate that includes both the IP and the hostname?

Mind you, I believe that the current best practices are not to issue SSL Certificates for IP addresses these days, of course if these are internal cert's then you won't have an issue about that.

  • Certs aren't issued with any particular IP address encoded. While switching to a single wildcard or SAN cert might solve this problem, those certs tend to be more expensive and overkill for a simple setup with only 2 hostnames and 2 sites. – Jordan Rieger Mar 31 '17 at 15:52

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.