У меня есть сайт A в IIS 8.0, настроенный на сертификат SSL с привязкой ###. ###. ###. ###: 443. У меня также есть сайт B, настроенный на разные сертификат с привязкой ###. ###. ###. ###: 443 (тот же IP-адрес, но host = sub.domain.com) Для привязки сайта B я установил флажок SNI enabled, поэтому IIS разрешил это.
Проблема в том, что я обнаружил, что загрузка сайта B из браузера с поддержкой SNI служит сертификатом для сайта A. Я предполагаю, что это связано с тем, что привязка сайта A технически удовлетворена, поэтому IIS перестает искать другие привязки для обслуживания запроса. (Я заметил, что netsh http show sslcert Команда, похоже, сначала показывает привязку сайта A в порядке отображения, хотя я понятия не имею, имеет ли этот порядок смысл.)
Есть ли способ изменить порядок привязки в IIS, чтобы он сначала пытался привязать запросы к привязке SNI-хоста сайта B, а только после этого возвращался к привязке сайта A без SNI (IP: только порт)? (Для совместимости с устаревшими версиями я не хочу включать SNI для привязки сайта A.)
Инструмент администрирования ведет себя недостаточно стабильно, чтобы можно было упорядочить привязки.
Я думаю, причина этого в том, что ваши привязки должны быть достаточно однозначными, чтобы не требовать упорядочивания.
Обратите внимание, что под обложками MMC веб-администратора (и Microsoft.Web.Administration API) управляют настройками как в файле конфигурации сервера IIS, так и в нем. и в настройках сетевого уровня ОС, которые, я думаю, находятся в реестре.
Я использовал netsh, чтобы посмотреть на привязки, создаваемые инструментами, и обнаружил, что порядок в файле конфигурации iis и порядок, в котором элементы отображаются в netsh (netsh hhtp show sslcert), имеют различный и произвольный порядок отображения, и что даже если порядок 'правильно' Я все еще иногда не получаю сертификат, который я пытался настроить для домена.
Что я пытался сделать, так это назначить домены для виртуального сервера по IP-адресу в DNS, затем настроить все сертификаты SNI, плюс один сертификат с подстановочными знаками для виртуального сервера без SNI, только IP-адрес по умолчанию для этого виртуальный сервер / IP-адрес.
Кажется, это сработает, если вы какое-то время обезьяны с настройками, потому что правила привязки TLS применяются в некоторые порядок, который имеет тенденцию быть таким же или похожим на порядок добавления привязок, если вы предполагаете, что некоторые изменения сделают удаление и добавление.
Однако, если вы посмотрите на привязки в netsh, становится ясно, что то, что вы помещаете в привязки администратора iis, будет либо использовать SNI и игнорировать IP-адрес, либо использовать IP-адрес и игнорировать домен. IP-адрес в параметрах привязки SNI, хотя он отображается в диалоговом окне и в файле конфигурации iis, не передается в конфигурацию сетевого уровня, который управляет TLS, и домен SNI получит этот сертификат для любого IP-адреса на сервер.
Итак, сервер может использовать либо SNI или сертификат с подстановочным знаком, но использование обоих и попытки заставить службы использовать сначала совпадают SNI, а подстановочный знак для всего остального на самом деле не поддерживается. Иногда это работает, но любое редактирование конфигурации или даже перезагрузка могут изменить порядок обработки внутри сетевого уровня.
Если вы хотите упорядочить привязки для применения неоднозначного сочетания правил ipaddress и SNI, ответ - нет, вы не можете делать это последовательно и предсказуемо. Если все домены / поддомены для IP-адреса используют один и тот же сертификат с подстановочными знаками, вы можете настроить несколько виртуальных серверов для использования IP-адреса и без SNI, но если вам нужно несколько сертификатов на одном IP-адресе, вам понадобится привязка SNI для каждый поддомен на сервере.
Единственное исключение из правила SNI / IPaddress или / или состоит в том, что даже если вы используете SNI, вы можете назначить один сертификат будет сертификатом по умолчанию для сервера (всех виртуальных серверов), выбрав «все неназначенные» для IP-адреса и без SNI. Этот сертификат будет использоваться для любого IP-адреса и любого домена, но только для запросов, которые не соответствуют никакому другому указанному правилу привязки. Похоже, это рассматривается как особый случай, администраторская MMC может даже предупреждать, если вы не настроили ее, об отсутствии привязки https по умолчанию для браузеров, которые не поддерживают SNI ...
Конечно, если вы (читатель, а не оригинальный плакат) не пытаясь смешать SNI с привязками IP-адреса, отличными от sni, но просто пытаясь управлять длинным списком привязок в пользовательском интерфейсе, вы можете щелкнуть заголовок 'hostname', и это будет отсортировать список по этому столбцу (щелкните еще раз, чтобы изменить возрастание / по убыванию) для исходного вопроса, вы можете использовать исключение «все неназначенные» для первого домена. Привязка SNI уже функционально «не назначена», поскольку IP-адрес игнорируется для привязок SNI.
Почему бы не изменить сертификат, используемый для одного сертификата, который включает как IP-адрес, так и имя хоста?
Имейте в виду, я считаю, что в настоящее время передовой практикой является не выпускать сертификаты SSL для IP-адресов, конечно, если это внутренние сертификаты, у вас не будет проблем с этим.