Не удается отключить 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
1 ответ
Одна вещь, которую я не упомянул, это то, что я использую централизованное хранилище сертификатов 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.pfxblue.com.pfxgreen.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 список и сайт работали нормально с ХР:-)
(Я должен был сделать это только для dog.com, Остальные сайты с животными по-прежнему настроены на использование центрального магазина).
Вы сказали,
Я размещаю их на одном сервере IIS, используя один IP-адрес для каждой семьи.
Это именно тот сценарий, для которого был разработан SNI.
SNI [...] позволяет серверу предоставлять несколько сертификатов на один и тот же IP-адрес и номер порта TCP и, следовательно, позволяет обслуживать несколько защищенных (HTTPS) веб-сайтов (или любой другой службы через TLS) с одного IP-адреса без необходимости использования всех эти сайты используют один и тот же сертификат.
Поскольку сайты используют один и тот же IP-адрес и порт, единственный способ отличить их - это доменное имя. Но без поддержки SNI сервер не имеет доступа к доменному имени в то время, когда он решает, какой сертификат отправить клиенту. Это связано с тем, что клиент еще не отправил запрос, а имя домена правильно является частью HTTP-запроса.