2

[Извините, если этот вопрос немного длинный, есть много дополнительной информации, если это актуально]

обзор

У меня проблема с SSL на ферме с балансировкой нагрузки на 4 ВМ в Azure. Если запрос HTTPS отправляется на первый сервер в ферме, все в порядке. Если он прибывает в любой из 3 других, то вызов не выполняется. Chrome выдаст ошибку протокола SSL, IE и Firefox просто скажут, что страница не может быть отображена.

Настройка

У меня есть четыре виртуальные машины Windows Server 2012 на Azure (маленький экземпляр, как только тестирование). Виртуальные машины находятся в одном облачном сервисе и имеют доступный набор Конечные точки с балансировкой нагрузки были добавлены для портов 80 и 443 (прямой возврат сервера НЕ включен на этих портах). Все четыре компьютера были настроены с помощью одного и того же сценария PowerShell и, за двумя исключениями, были полностью настроены таким образом.

Конфигурация IIS каждого сервера настроена на использование конфигурации общего ресурса, которая реплицируется через DFS на каждый сервер с первого сервера в группе. Это было настроено вручную для каждого сервера и работает нормально.

DFS также используется для репликации папки webs с первого сервера на другие.

Я также обнаружил "новую" функцию централизованных сертификатов после написания сценария развертывания, поэтому она была установлена и настроена вручную на четырех серверах. Я использую общий ресурс на отдельном сервере для хранения файлов сертификатов.

Запрос сертификата был сгенерирован на первом сервере, и я использовал SSL.com, чтобы получить бесплатный 90-дневный SSL для адреса subdomain.domain.com . Я добавил запись CNAME для subdomain в DNS для domain.com указывающую на адрес cloudapp Azure.

Я импортировал сертификат SSL на первый сервер, затем снова экспортировал его как subdomain.domain.com.pfx (с паролем) и скопировал его в общую папку файлов сертификатов. При проверке централизованных сертификатов на всех четырех серверах они выводят список сертификатов без значков ошибок, указывающих на неправильный пароль в конфигурации и т.д.

Наконец, я изменил привязки сервера 1, чтобы добавить https с именем хоста subdomain.domain.com и с установленными параметрами Требовать указание имени сервера и Использовать централизованное хранилище сертификатов . Проверка других серверов показывает, что привязки распространяются, как и ожидалось.

Эта проблема

Я добавил базовую страницу, которая просто показывает имя сервера, на котором был обработан запрос. Если я обработаю несколько окон IE, обращающихся к http://subdomain.domain.com , они распечатают различные имена серверов, показывая, что конфигурация IIS и веб-файлы развертываются правильно, и механизм балансировки нагрузки Azure тоже делает свое дело , Который я нашел действительно классным на самом деле.

Тем не менее, он выходит из строя, когда я пытаюсь это через HTTPS. Только запросы, попавшие на первый сервер, выполняются успешно, остальные сбои и записи с "Эта страница не может быть отображена" или "Ошибка протокола SSL" в зависимости от того, с каким браузером я тестирую. На сервере 1 страница отображается нормально, сертификат доступен для просмотра и нет ошибок сертификата.

Я уверен, что это проблема конфигурации на серверах где-то, но я просто не могу сказать, что это такое. Большая часть того, с чем я играю, является новой для меня, поскольку в прошлом мы использовали физические некластеризованные серверы Windows 2003 с IIS6.

Что еще более озадачивает, так это то, что я отключаю четыре виртуальные машины на ночь, и когда я перезапускаю службу сегодня утром, сервер 2 теперь, очевидно, отвечает на запросы SSL в дополнение к серверу 1. С учетом вышесказанного я вчера тоже полностью отключился, и после этого все еще работал только сервер 1.

В файлах журнала IIS не отображаются сбойные запросы SSL, только группа из 200 для порта 80 и смесь 200 и 304 для порта 443 на сервере 1 и 2.

Я провел некоторую тщательную проверку в поисках Google, но ничто не проливает свет. На самом деле, полная противоположность тому, что я могу сказать, то, что я сделал, должно сработать.

Любые советы, которые помогут решить эту проблему, будут с благодарностью приняты.

|источник

1 ответ1

1

Я хотел поделиться некоторыми шагами, которые должны решить большинство проблем с Централизованным хранилищем сертификатов на IIS. Централизованное хранилище сертификатов (CCS) создает привязку поддельного сертификата, которую он использует для направления запросов SSL-сертификатов через CCS. Если эта привязка отсутствует или имеется несколько привязок на одном и том же IP-адресе, вы будете получать ошибки браузера, когда клиенты пытаются подключиться к веб-сайтам с поддержкой SSL.

Рассмотрим следующую настройку; сервер IIS с IP-адресом 172.16.0.41 и включенным централизованным хранилищем сертификатов содержит два домена; www.adomain.com и www.bdomain.com . Пакеты сертификатов PFX устанавливаются в централизованном хранилище сертификатов IIS для каждого из доменов.

Обычно есть две ошибки;

ПРОБЛЕМА 1

Когда браузеры подключаются к сайту, неверный сертификат распространяется. Например, при первом посещении www.adomain.com правильный сертификат, однако, когда браузер заходит на сайт www.bdomain.com , возвращается сертификат для www.adomain.com , в результате чего браузер отмечает неверный сертификат.

РЕШЕНИЕ

Причина этой проблемы обычно заключается в том, что несколько веб-сайтов связаны с одним и тем же IP-адресом, и по крайней мере на одном из веб-сайтов не включен параметр « Требовать идентификацию имени сервера». Если этот параметр не включен для всех веб-сайтов, использующих один и тот же IP-адрес и порт, IIS не может определить, какой сертификат следует обслуживать, и поэтому, по-видимому, применяется первый в выигрыше .

Это означает, что последующие запросы к другим веб-сайтам, размещенным на том же сервере IIS, возвращают неправильный сертификат.

Шаги, чтобы решить

  1. Убедитесь, что на каждом веб-сайте установлен параметр Require Server Name Identification . Сделайте это, нажав на каждом веб-сайте в диспетчере IIS, выбрав «Привязки» -> Выберите «Привязка HTTPS» -> «Выбрать» -> «Проверить» - « Require Server Name Identification и убедитесь, что также проверено Use Centralized Certificate Store .

  2. Проверьте привязки на сервере. В командной строке с повышенными правами выполните команду netsh http show sslcert

Привязка для CCS должна присутствовать: 

SSL Certificate bindings:
------------------------- 

Central Certificate Store    : 443
Certificate Hash             : (null)
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : (null)
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

Обратите внимание, что привязка с (null) хешем сертификата указывает на наличие сквозной привязки CCS. Если есть какие-либо другие привязки, прослушивающие IP-адрес вашего сервера и порт SSL (172.16.0.41:443 в нашем сценарии), их необходимо удалить.

  1. Чтобы удалить привязки, введите netsh http delete sslcert <binding> . В нашем сценарии это будет netsh http delete sslcert 172.16.0.41:443 и привязка должна быть удалена. (null) сквозное связывание CCS не должно быть удалено. Если эта привязка отсутствует, см. ПРОБЛЕМУ 2 ниже.

  2. Сбросьте iis с помощью iisreset и подключитесь к каждому домену на веб-сервере. Правильный сертификат должен быть предоставлен. Вы также можете проверить привязки, повторив шаг 2 и убедившись, что нет конкретных привязок IP:PORT к вашему порту SSL и IP веб-сервера.

ПРОБЛЕМА 2

Даже после подтверждения того, что Централизованное хранилище сертификатов включено, оно имеет видимость на сертификатах, и все веб-сайты обязаны использовать его, когда браузер подключается к веб-сайту, он выдает Page Cannot be displayed или invalid encryption ошибка шифрования . Предполагаемый веб-сайт не отображается.

В IE (Edge) это обычно проявляется как предложение проверить, включены ли в браузере соответствующие типы шифрования.

iisreset или перезагрузка сервера не решают проблему.

РЕШЕНИЕ

Это похоже на ошибку в создании сквозной привязки CCS. Он не создается на веб-сервере, когда включена функция CCS, поэтому входящие запросы на сертификат молча отбрасываются.

Шаги, чтобы решить

  1. Сначала проверьте, что Централизованное хранилище сертификатов включено и может видеть все сертификаты на своем пути. Для этого установите флажок IISManager выберите узел сервера-> Централизованные сертификаты (в разделе «Управление»)-> Изменить параметры компонента и убедитесь, что он настроен и включен.

  2. Убедитесь, что все сайты, которые используют общие сертификаты, связаны с CCS. Сделайте это, нажав на каждом веб-сайте в диспетчере IIS, выбрав «Привязки» -> Выберите «Привязка HTTPS» -> «Выбрать» -> «Проверить» - « Require Server Name Identification и убедитесь, что также проверено Use Centralized Certificate Store .

  3. Проверьте, что привязка CCS была создана. Запустите netsh http show sslcert . Если результаты пусты или отсутствует (null) сертификат прохождения (см. Шаг 2 в ПРОБЛЕМЕ 1, как выглядит привязка CCS), привязка CCS не была включена. 

    SSL Certificate bindings:
-------------------------

  4. В диспетчере IIS, выбрав один веб-сайт, который использует CCS, нажмите «Привязки» -> Выберите «Привязка HTTPS» -> «Изменить» -> и снимите флажок « Use Centralized Certificate Store и снимите флажок « Require Server Name Identification .

В раскрывающемся списке « Сертификат SSL certificate выберите сертификат WMSVC умолчанию для серверов и нажмите « OK . Оставьте окно « Site Bindings открытым.

  1. Вернитесь в командную строку с повышенными правами и запустите netsh http show sslcert . Это должно привести к привязке следующим образом:

    SSL Certificate bindings:
------------------------- 
IP:port                      : 172.16.0.41:443
Certificate Hash             : 64498c920fecb31b8f7ccbdac2fa2baa2ec4f19a
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

  2. Вернитесь в окно « Site Bindings и отмените изменения, начиная с шага 4. Включите параметр « Require Server Name Indication и « Use Centralized Certificate Store и нажмите « OK .

  3. Вернитесь в командную строку с повышенными привилегиями и снова запустите команду netsh http show sslcert и, если вам улыбнутся боги, привязка к централизованному хранилищу сертификатов должна была возникнуть, заменив текущую привязку: 

      SSL Certificate bindings:
  -------------------------

  Central Certificate Store    : 443
  Certificate Hash             : (null)
  Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
  Certificate Store Name       : (null)
  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

Если вы видите вышеупомянутое связывание сертификата с (null) значащим Certificate Hash это сработало, и теперь должен быть включен проход CSS.

  1. Запустите браузер и попытайтесь подключиться к доменам на сервере через безопасный сокет (HTTPS), и все должно быть в порядке.

Важные заметки

  • Вам нужно повторить этот процесс на каждом веб-сервере вашей веб-фермы. Это должно быть выполнимо через PowerShell для автоматизации и проверки процесса.

  • После создания сквозной привязки она будет сохраняться в течение неопределенного времени (если вы не отключите поддержку централизованного сертификата на узле).

Как в сторону; эта ссылка содержит информацию о том, как CCS работает на техническом уровне, и ее стоит прочитать: https://blogs.msdn.microsoft.com/kaushal/2012/10/11/central-certificate-store-ccs-with-iis. -8-Windows-сервер-2012/

Надеюсь, это поможет.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .