☰

Ошибка SSL на веб-ферме Auzre с общей конфигурацией и централизованными сертификатами

tag-icon • tag-icon ssl certificate iis windows-server-2012 azure
Ошибка SSL на веб-ферме Auzre с общей конфигурацией и централизованными сертификатами

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

Обзор

У меня проблема с 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указания на адрес Azure cloudapp.

Я импортировал сертификат 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

Я хотел бы поделиться некоторыми шагами, которые должны решить большинство проблем с централизованным хранилищем сертификатов на 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 pass through. Если есть какие-либо другие привязки, прослушивающие 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-server-2012/

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

Связанный контент