Назад | Перейти на главную страницу

Могу ли я запретить IIS получать промежуточные сертификаты SSL через AIA?

В соответствии с этот ответ IIS может использовать расширение сертификата доступа к информации о полномочиях для получения отсутствующего сертификата эмитента.

Вот сценарий. Есть установка IIS с конечной точкой HTTP, имеющей сертификат SSL. Обычно владелец IIS должен также установить все промежуточные сертификаты в локальное хранилище «Промежуточных центров» («CA»), чтобы при подключении клиента сервер мог отправить всю цепочку, кроме корневого сертификата. Однако владелец IIS может забыть установить промежуточный сертификат. Затем в соответствии с этим ответом IIS будет использовать AIA, извлекать промежуточный сертификат и продолжать обслуживать его для всех клиентов.

Похоже, это поведение по умолчанию, и я не могу найти, как его можно изменить.

Могу ли я запретить IIS получать промежуточные сертификаты? Для этого есть какие-то настройки?

Похоже, что нет ничего лучше подробной документации для этого поведения, но небольшое количество тестов черного ящика показывает, что это поведение постоянно и может быть подавлено только путем блокировки соединения между сервером и инфраструктурой CA с помощью правила брандмауэра. Вот как это можно сделать для веб-ролей Azure с помощью osFamily=3 (Windows Server 2012):

  1. В .csdef не указывайте промежуточный сертификат в <Certificates> элемент.
  2. Определите диапазон IP-адресов, на который отвечает инфраструктура CA. Для этого проверьте свой сертификат и найдите некоторый URI AIA или OCSP в свойствах сертификата, затем используйте ping чтобы найти IP-адрес.
  3. Создать группа безопасности сети в Azure с правилом брандмауэра, разрешающим входящие подключения с любых адресов (чтобы вы могли получить доступ к своей службе и проверять работу SSL) и запрещающим исходящие подключения к диапазону IP-адресов ЦС (это ключ к эксперименту).
  4. Создать виртуальная сеть в Azure и внутри нее создайте подсеть и привяжите ее к указанной выше группе безопасности сети.
  5. Измените ваш .cscfg, добавив <NetworkConfiguration> инструкции по развертыванию службы в ранее созданной виртуальной сети и (ключевой момент) развертыванию вашей веб-роли в ранее созданной подсети. Установите количество экземпляров равным 1 для облегчения тестирования.

Теперь ты готов. Разверните службу и наблюдайте, как сторонние инструменты сообщают, что промежуточный сертификат не обслуживается. Измените правило брандмауэра на «разрешить» и воссоздать образ экземпляр роли - после перезапуска сторонние инструменты сообщают, что промежуточное звено теперь обслуживается. Измените правило на "запретить" и воссоздать образ экземпляр - промежуточное звено больше не обслуживается.

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

Вот почему в облачных службах Azure всегда должны быть все промежуточные сертификаты, перечисленные в .csdef, чтобы гарантировать их развертывание на экземпляре, независимо от того, доступна ли инфраструктура центра сертификации в момент развертывания.