Поделиться через


Сертификаты Брандмауэра Azure уровня "Премиум"

Чтобы правильно настроить проверку TLS для Брандмауэра Azure уровня "Премиум", необходимо предоставить допустимый промежуточный сертификат ЦС и поместить его в хранилище ключей Azure.

Сертификаты, используемые Брандмауэром Azure уровня "Премиум"

В типичном развертывании используется три типа сертификатов:

  • Промежуточный сертификат ЦС (сертификат ЦС)

    Центр сертификации (ЦС) — это организация, которая является доверенной для подписания цифровых сертификатов. Центр сертификации проверяет удостоверение и подлинность компании или лица, запрашивающего сертификат. Если проверка проходит успешно, ЦС выдает подписанный сертификат. Когда сервер предоставляет сертификат клиенту (например, веб-браузеру) во время подтверждения SSL/TLS, клиент пытается проверить подпись по списку известных надежных подписывающих. Веб-браузеры обычно содержат списки удостоверяющих центров, которым они доверяют для идентификации хостов. Если удостоверяющий центр нет в списке, как в случае с некоторыми сайтами, которые подписывают свои собственные сертификаты, браузер предупреждает пользователя о том, что сертификат не подписан доверенным удостоверяющим центром, и спрашивает, хочет ли пользователь продолжить взаимодействие с непроверенным сайтом.

  • Сертификат сервера (сертификат веб-сайта)

    Сертификат, связанный с определенным доменным именем. Если у веб-сайта есть действительный сертификат, это означает, что ЦС выполнил действия по проверке принадлежности веб-адреса этой организации. При вводе URL-адреса или переходе по ссылке на безопасный веб-сайт браузер проверяет сертификат на наличие следующих характеристик:

    • адрес веб-сайта соответствует адресу сертификата;
    • Сертификат подписан центром сертификации, который браузер распознает как доверенный авторитет.

    Иногда пользователи могут подключаться к серверу с недоверенным сертификатом. Брандмауэр Azure завершит подключение, как если бы подключение прервал сервер.

  • Сертификат корневого ЦС (корневой сертификат)

    Центр сертификации может выдавать несколько сертификатов в виде иерархической структуры. Корневой сертификат — это самый верхний сертификат дерева.

Брандмауэр Azure уровня "Премиум" позволяет перехватывать исходящий трафик HTTP/S и автоматически создавать сертификат сервера для www.website.com. Этот сертификат создается с помощью предоставляемого вами промежуточного сертификата ЦС. Чтобы этот процесс выполнялся, браузер и клиентские приложения (IaaS, PaaS и другие рабочие нагрузки) конечного пользователя должны доверять сертификату корневого ЦС организации или сертификату промежуточного ЦС.

Процесс использования сертификата

Требования к промежуточным сертификатам ЦС

Убедитесь, что сертификат ЦС соответствует указанным ниже требованиям:

  • При развертывании в качестве секрета Key Vault необходимо использовать PFX без пароля (PKCS12) с сертификатом и закрытым ключом. Сертификаты PEM не поддерживаются.

  • сертификат должен быть один и не включать в себя всю цепочку сертификатов;

  • срок действия сертификата должен истекать не раньше, чем через год;

  • сертификат должен быть закрытым ключом RSA с минимальным размером 4096 байт;

  • Сертификат должен иметь расширение KeyUsage, отмеченное как критическое при помощи флага KeyCertSign (RFC 5280; 4.2.1.3 Использование ключа).

  • У сертификата должно быть расширение BasicConstraints, помеченное как критическое (RFC 5280; 4.2.1.9 Основные ограничения).

  • для флага CA должно быть установлено значение TRUE;

  • длина пути должна быть больше единицы или равна единице.

  • Он должен быть экспортируемым.

Azure Key Vault

Управляемое платформой хранилище секретов Azure Key Vault можно применять для защиты секретов, ключей и сертификатов TLS/SSL. Брандмауэр Azure уровня "Премиум" поддерживает интеграцию с Key Vault для сертификатов сервера, подключенных к политике брандмауэра.

Чтобы настроить хранилище ключей:

  • Импортируйте существующий сертификат с его парой ключей в хранилище ключей.
  • ** В качестве альтернативы, можно использовать секрет хранилища ключей, который хранится в виде PFX-файла без пароля в кодировке Base64. PFX-файл — это цифровой сертификат, содержащий закрытый и открытый ключи.
  • Рекомендуется использовать импорт сертификатов ЦС, так как в таком случае вы сможете настроить оповещение на основе даты истечения срока действия сертификата.
  • После импорта сертификата или секрета необходимо определить политики доступа в хранилище ключей, чтобы предоставить удостоверению доступ к сертификату (секрету).
  • Указанный сертификат ЦС должен быть доверенным для рабочей нагрузки Azure. Убедитесь, что они развернуты правильно.
  • Так как Брандмауэр Azure Premium указана в качестве доверенной службы Key Vault, она позволяет обойти внутренний брандмауэр Key Vault и исключить любой доступ к Хранилищу ключей в Интернете.

Примечание.

При импорте нового сертификата ЦС брандмауэра в Azure Key Vault (в первый раз или заменив сертификат ЦС с истекшим сроком действия), необходимо явно обновить параметр TLS политики Брандмауэр Azure с новым сертификатом.

Вы можете создать или повторно использовать существующее назначенное пользователем управляемое удостоверение, которое Брандмауэр Azure использует для получения сертификатов от Key Vault от вашего имени. Дополнительные сведения см. в статье Что такое управляемые удостоверения для ресурсов Azure.

Примечание.

Управление доступом на основе ролей Azure (Azure RBAC) в настоящее время не поддерживается для авторизации. Вместо этого используйте модель политики доступа. Дополнительные сведения см. в статье "Управление доступом на основе ролей Azure" (Azure RBAC) и политики доступа.

Настройка сертификата в политике

Чтобы настроить сертификат ЦС в политике Брандмауэра уровня "Премиум", выберите политику, а затем выберите Проверка TLS. Выберите Включено на странице Проверка TLS. Затем выберите сертификат ЦС в Azure Key Vault, как показано на следующем рисунке.

Обзорная схема брандмауэра Azure уровня

Внимание

Чтобы посмотреть и настроить сертификат из портала Azure, необходимо добавить учетную запись пользователя Azure в политику доступа к Key Vault. Предоставьте вашей учетной записи разрешения Получить и Перечислить в разделе Разрешения секретов. Политика доступа к Azure Key Vault

Создайте свой собственный самозаверяющий сертификат Удостоверяющего Центра

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

Внимание

Для производства следует использовать вашу корпоративную инфраструктуру открытых ключей для создания промежуточного сертификата ЦС. Корпоративная PKI использует существующую инфраструктуру и обеспечивает распределение корневого центра сертификации на всех конечных машинах. Дополнительные сведения см. в статье Развертывание и настройка сертификатов ЦС предприятия для Брандмауэра Azure.

Существуют две версии скрипта:

  • скрипт Bash cert.sh;
  • скрипт PowerShell cert.ps1.

Кроме того, оба скрипта используют файл конфигурации openssl.cnf. Чтобы использовать скрипты, скопируйте на локальный компьютер содержимое openssl.cnf, а также cert.sh или cert.ps1.

Скрипты создают следующие файлы:

  • rootCA.crt/rootCA.key — открытый сертификат корневого ЦС и закрытый ключ;
  • interCA.crt/interCA.key — промежуточный открытый сертификат ЦС и закрытый ключ;
  • interCA.pfx — pkcs12-пакет для промежуточного ЦС, который будет использовать брандмауэр.

Внимание

rootCA.key необходимо хранить в безопасном автономном расположении. Скрипты создают сертификат со сроком действия 1024 дня. Для скриптов требуется, чтобы на локальном компьютере были установлены двоичные файлы OpenSSL. Дополнительные сведения см. в статье https://www.openssl.org/

После создания сертификатов разверните их в следующих расположениях:

  • rootCA.crt — установите на конечные машины (только публичный сертификат).
  • interCA.pfx — импортируйте сертификат в Key Vault и назначьте его политике брандмауэра.

openssl.cnf

[ req ]
default_bits        = 4096
distinguished_name  = req_distinguished_name
string_mask         = utf8only
default_md          = sha512

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

[ rootCA_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ interCA_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:1
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:false
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth

Сценарий Bash — cert.sh

#!/bin/bash

# Create root CA
openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -sha256 -days 1024 -out rootCA.crt -subj "/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA" -config openssl.cnf -extensions rootCA_ext

# Create intermediate CA request
openssl req -new -nodes -newkey rsa:4096 -keyout interCA.key -sha256 -out interCA.csr -subj "/C=US/ST=US/O=Self Signed/CN=Self Signed Intermediate CA"

# Sign on the intermediate CA
openssl x509 -req -in interCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out interCA.crt -days 1024 -sha256 -extfile openssl.cnf -extensions interCA_ext

# Export the intermediate CA into PFX
openssl pkcs12 -export -out interCA.pfx -inkey interCA.key -in interCA.crt -password "pass:"

echo ""
echo "================"
echo "Successfully generated root and intermediate CA certificates"
echo "   - rootCA.crt/rootCA.key - Root CA public certificate and private key"
echo "   - interCA.crt/interCA.key - Intermediate CA public certificate and private key"
echo "   - interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault"
echo "================"

PowerShell — cert.ps1

# Create root CA
openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -sha256 -days 3650 -out rootCA.crt -subj '/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA' -config openssl.cnf -extensions rootCA_ext

# Create intermediate CA request
openssl req -new -nodes -newkey rsa:4096 -keyout interCA.key -sha256 -out interCA.csr -subj '/C=US/ST=US/O=Self Signed/CN=Self Signed Intermediate CA'

# Sign on the intermediate CA
openssl x509 -req -in interCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out interCA.crt -days 3650 -sha256 -extfile openssl.cnf -extensions interCA_ext

# Export the intermediate CA into PFX
openssl pkcs12 -export -out interCA.pfx -inkey interCA.key -in interCA.crt -password 'pass:'

Write-Host ""
Write-Host "================"
Write-Host "Successfully generated root and intermediate CA certificates"
Write-Host "   - rootCA.crt/rootCA.key - Root CA public certificate and private key"
Write-Host "   - interCA.crt/interCA.key - Intermediate CA public certificate and private key"
Write-Host "   - interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault"
Write-Host "================"

Автоматическое создание сертификатов

Для отличных от рабочих развертываний можно использовать механизм автоматического создания сертификатов для Брандмауэра Azure уровня "Премиум", который автоматически создает следующие три ресурса:

  • Управляемая идентификация
  • Хранилище ключей
  • самозаверяющий корневой сертификат ЦС.

Просто выберите новое управляемое удостоверение, и оно свяжет три ресурса в политике уровня "Премиум", а также настроит проверку TLS.

Снимок экрана: автоматически созданные сертификаты.

Устранение неполадок

Если сертификат ЦС действителен, но вы не можете получить доступ к полным доменным именам или URL-адресам при проверке TLS, проверьте следующее:

  • Убедитесь, что сертификат веб-сервера действителен.

  • Убедитесь, что сертификат корневого ЦС установлен в клиентской операционной системе.

  • Убедитесь, что в браузере или HTTPS-клиенте содержится действительный корневой сертификат. У Firefox и других браузеров могут быть особые политики сертификации.

  • Убедитесь, что в правиле вашего приложения тип назначения URL-адреса охватывает правильный путь и любые другие гиперссылки, встроенные в целевую HTML-страницу. Вы можете использовать подстановочные знаки, чтобы упростить охват всего необходимого URL-пути.

Следующие шаги