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.)
The administration tool does not behave consistently enough to allow you to order the bindings.
The reason for this, I think, is that your bindings are supposed to be unambiguous enough to not require ordering.
Note that under the covers, the web admin MMC (and Microsoft.Web.Administration API) are managing settings both in the IIS server config file, and in the OS network layer settings, which I think are in the registry.
I used netsh to look at the bindings the tools create, and found that the order in the iis config file and the order things are displayed in netsh (netsh hhtp show sslcert) are differently and arbitrarily ordered in display and that even when the ordering is 'right' I still sometimeS don't get the certificate I tried to configure for the domain.
What I was trying to to do was to assign domains for a virtual server by IP address in DNS, then set up all the SNI certs, plus one wildcard cert per virtual server with no SNI, just the IP address to be the default for that virtual server/ip address.
This seems to work if you monkey with the settings for a while, because the TLS binding rules are applied in some order, which tends to be the same or similar to the order the bindings were added, if you assume some edits will do a remove and an add.
However, when you look at the bindings in netsh, it becomes clear that what you put into iis admin bindings will either use SNI and ignore IP address, or use IP address and ignore the domain. The IP address in the SNI binding settings, while it appears in the dialog box and the iis config file, is not passed on to the configuration of the network layer that manages TLS, and the SNI domain will get that certificate for any IP address on the server.
So, a server can use either SNI or a wildcard cert, but using both and trying get the services to use the SNI matches first and a wildcard for everything else is not really supported. It appears to work sometimes, but any configuration edit or even a reboot can change the processing order inside the network layer.
If you are wanting to order bindings to apply an ambiguous mix of ipaddress and SNI rules, the answer is no, you can't consistently and predictably do that. If all the domains/subdomains for an IP address use the same wildcard cert, you can set up several virtual servers to use the IP address and no SNI, but if you need multiple certs on the same IP address, you need an SNI binding for each subdomain on the server.
The single exception to the SNI / IPaddress either/or rule is that even if you are using SNI, you can assign one certificate to be the default certificate for the server (all virtual servers) by choosing 'all unnasigned' for IP address and no SNI. That certificate will be used for any IP and any domain, but only for requests that don't match any other specified binding rule. This seems to be treated as a special case, the admin MMC may even warn when you don't set one up about not having a default https binding for browsers that don't support SNI...
Of course, if you (the reader, not the original poster) are not trying to mix SNI with non-sni IPaddress bindings, but just trying to manage a long list of bindings in the UI, you can click on the 'hostname' header and that will sort the list by that column (click again to change ascending/descending) for the original question, you can use the 'all unassigned' exception for the first domain. The SNI binding is already functionally 'all unassigned', since IP address is ignored for SNI bindings.
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.