Не может отключить SNI на Windows Server 2012
У меня есть два различных 'семейства' связанных сайтов, каждого с их собственным сертификатом UCC на том же сервере.
Я размещаю их на том же сервере IIS, с помощью одного IP-адреса для каждого семейства.
Оба UCC certficates от 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:port. В соответствии с этой статьей, если бы 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 Centralized Certificate Store - что оказалось важным.
Для моих сайтов давайте представим, что это следующие группы (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, и сайт отлично работал с XP :-)
(Мне нужно было сделать это только для dog.com. Остальные сайты животных все еще настроены на использование центрального магазина)
Вы сказали,
я размещаю их на одном сервере IIS, используя один IP-адрес для каждой семьи.
Это именно тот сценарий, для которого SNI был разработан.
SNI [...] позволяет серверу представлять несколько сертификатов на один и тот же IP-адрес и номер порта TCP и, следовательно, позволяет нескольким защищенным (HTTPS) веб-сайтам (или любой другой службе через TLS) обслуживаться одним и тем же IP-адресом. не требуя, чтобы все эти сайты использовали один и тот же сертификат.
Поскольку сайты используют один и тот же IP-адрес и порт, отличить их можно только по доменному имени. Но без поддержки SNI сервер не имеет доступа к доменному имени в то время, когда он решает, какой сертификат отправить клиенту. Это связано с тем, что клиент еще не отправил запрос, а доменное имя является частью HTTP-запроса.