Не удается отключить SNI в Windows Server 2012
У меня есть два разных «семейства» связанных сайтов, каждый со своим собственным сертификатом UCC на одном сервере.
Я размещаю их на одном сервере IIS, используя один IP-адрес для каждой семьи.
Оба сертификата UCC получены от GoDaddy.
Каждая из привязок (для каждой SAN в UCC) отключена «Требовать указание имени сервера».
Однако, когда я пытаюсь перейти на сайт из IE 8 в Windows XP, работает только одно из «семейств» сайтов. Другой просто не ведет переговоры.
При анализе SSL на SSLLabs.com Я получаю следующий результат: «Этот сайт работает только в браузерах с поддержкой SNI».
Но как это возможно! Я отключил «Требовать SNI» для каждой привязки: 443.
Я даже посмотрел на applicationHost.config файл и нет ни одного сайта с sslFlags="1" указывает на то, что этот параметр включен. Да, я тоже перезапустил IIS.
В чем дело. Я очень озадачен. Мне интересно, могу ли я каким-то образом полностью отключить SNI на сервере или что могло бы спровоцировать это. Вчера я делал несколько месяцев обновлений Windows, но, честно говоря, я думаю, что так было долгое время, и я даже не подозревал об этом - на основе 0 долларов продаж от клиентов IE8 XP ;-)
Редактировать: Я действительно думаю, что мой IIS поврежден. Когда я бегу netsh http show sslcert каждая привязка имеет вид IP: порт. В соответствии с Эта статья если SNI включен, я бы увидел hostname:port и я не вижу записей в этом формате. Также нет записей в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslSniBindingInfo в реестре - но я подтвердил, что здесь создается новый, если я временно добавлю привязку SNI.
IP:port : 10.0.0.2:443
Certificate Hash : d59a149e6678bc10d62093401c5b705cc23094be
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Я не упомянул одну вещь: я использую Централизованное хранилище сертификатов IIS - что оказалось важным.
Для моих сайтов давайте представим, что это следующие группы (IP-адрес является внутренним и отображается через брандмауэр).
Group A : red.com, blue.com, green.com (UCC certificate A) 10.0.0.1
Group B : cat.com, dog.com, mouse.com (UCC certificate B) 10.0.0.2
Группа A - это группа, которая работала так, как я хотел (не сообщая, что для этого требуется SNI). Группа B не работала на XP с IIS 8.
В моем хранилище сертификатов у меня есть несколько копий каждого сертификата (просто pfx файлы в файловой системе).
red.com.pfx blue.com.pfx green.com.pfx и т.д. для всех сайтов
Когда я запустил команду netsh http show sslcert оказывается, была только запись для 10.0.0.1:443 и не один для 10.0.0.2:443. Это было причиной различного поведения на каждом сайте.
IP:port : 10.0.0.1:443
Certificate Hash : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Disabled
Почему этот IP показывает запись? У меня также была дополнительная привязка к другому веб-сайту с тем же сертификатом для того же IP-адреса (используется для перенаправления без SSL на SSL).
Я предполагаю, что IIS предполагает, что если вы используете централизованное хранилище, вы используете SNI, поэтому кажется, что он неявно сообщает, что он этого требует, хотя на самом деле это не так.
Я смог [наконец] решить эту проблему, изменив один моих привязок для группы B, чтобы явно ссылаться на сертификат, а не просто искать его в магазине. После этого, конечно, 10.0.0.2:443 запись тогда присутствовала в netsh http show sslcert list и сайт нормально работал с XP :-)
(Мне нужно было сделать это только для dog.com. Остальные участки для животных по-прежнему будут использовать центральный магазин).
Ты сказал,
Я размещаю их на одном сервере IIS, используя один IP-адрес для каждой семьи.
Это именно тот сценарий SNI был разработан для.
SNI [...] позволяет серверу предоставлять несколько сертификатов на один и тот же IP-адрес и номер порта TCP и, следовательно, позволяет обслуживать несколько защищенных (HTTPS) веб-сайтов (или любой другой службы через TLS) с одного и того же IP-адреса без необходимости использования всех эти сайты используют один и тот же сертификат.
Поскольку сайты используют один и тот же IP-адрес и порт, единственный способ отличить их - это доменное имя. Но без поддержки SNI сервер не имеет доступа к доменному имени в то время, когда он решает, какой сертификат отправить клиенту. Это связано с тем, что клиент еще не отправил запрос, а имя домена правильно является частью HTTP-запроса.