Можно ли смешивать привязки SSI и не-SSI, один и тот же IP-адрес и порт в IIS 8.5

Я нашел хорошие ресурсы в блоге Microsoft, в котором подробно рассказывается о IIS, SNI, и даже некоторые CCS:

https://blogs.msdn.microsoft.com/kaushal/2012/09/04/server-name-indication-sni-with-iis-8-windows-server-2012/

Это отличный ресурс. Прочитал внимательно и комментарии. Судя по материалам этого блога, я думаю, что знаю ответ, но, как говорится, не повредит получить еще одну пару глаз.

У меня есть коробка с Windows Server 2012, IIS 8.5. Один IP-адрес. Он содержит один сайт с двумя SSL bindings. То есть HTTPS. Оба имеют порт 443 и каждый имеет свой уникальный сертификат. И поскольку существует только один IP-адрес, каждый из них имеет один и тот же IP-адрес. Одна привязка имеет Требовать указания имени сервера проверил и Имя хоста есть запись myserver.example.com. Другая привязка - это привязка SSL по умолчанию и, следовательно, Требовать указания имени сервера не отмечен и Имя хоста пусто.

(Кстати, основываясь на содержании указанного блога, я думаю, что мы можем ответить на вопрос, что произойдет, если Имя хоста введен, но Требовать указания имени сервера не отмечен. Ничего. Он возвращается к IP:Port.)

У меня есть вопрос, можно ли смешивать привязки SNI и не-SNI SSL на одном IP: Port?

На основании рабочего процесса, описанного в блоге (см. Ниже), и моего собственного тестирования, нет, он всегда будет выбирать привязку SSL, отличную от SNI. Но, возможно, я ошибаюсь, и я не вижу решения для смешивания привязок SNI и не-SNI с одним и тем же IP: Port.

    Below are the steps involved during SSL handshake between a SNI
    compliant Client and a site hosted on IIS 8 on which a SSL binding is 
    configured to use SNI.

    1. The client and the server establish a TCP connection via TCP 
       handshake.

    2. The client sends a Client Hello to the server. This packet contains 
       the specific protocol version, list of supported cipher suites along 
       with the hostname (let’s say www.outlook.com provided its a SNI 
       compliant browser). The TCP/IP headers in the packet contain the 
       IPAddress and the Port number.

    3. The server checks the registry (legacy bindings) to find a 
       certificate hash/thumbprint corresponding to the above combination of 
       IP:Port.

    4. If there is no legacy binding for that IP:Port, then server uses 
       hostname information available from the Client Hello checks the 
       registry to find a certificate hash corresponding to the above 
       combination of Hostname:Port. The server checks the below key to find 
       the combination:

        HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslSniBindingInfo

    5. If the above step fails i.e., if the server couldn’t find a 
       corresponding hostname:port, then it would use the IPAddress 
       available to search for a legacy SSL binding for that IPAddress and 
       PORT. (If this is absent then the SSL handshake would fail)

    6. Once it finds a match, the crypto API’s are called to retrieve the 
       Server Certificate based on the thumbprint/certificate hash from the 
       certificate store. The retrieved certificate is then added to the 
       Server Hello and sent to the client.