Сертификаты Брандмауэра 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 в политику доступа к Key Vault. Предоставьте учетной записи пользователя разрешения Получение и Перечисление в разделе Разрешения секретов.
Создание собственного самозаверяющего сертификата ЦС
Если вы хотите создать собственные сертификаты, для упрощенной проверки TLS воспользуйтесь следующими скриптами для создания собственного самозаверяющего корневого и промежуточного ЦС.
Внимание
Для рабочей среды следует создать промежуточный сертификат ЦС с помощью корпоративной инфраструктуры открытых ключей. Эта инфраструктура использует существующую инфраструктуру и выполняет распределение корневого ЦС на всех компьютерах конечных точек. Дополнительные сведения см. в статье Развертывание и настройка сертификатов ЦС предприятия для Брандмауэра 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 уровня "Премиум", который автоматически создает следующие три ресурса:
- Управляемое удостоверение
- Key Vault
- самозаверяющий корневой сертификат ЦС.
Просто выберите новое управляемое удостоверение, и оно свяжет три ресурса в политике уровня "Премиум", а также настроит проверку TLS.
Устранение неполадок
Если сертификат ЦС действителен, но вы не можете получить доступ к полным доменным именам или URL-адресам при проверке TLS, проверьте следующее:
Сертификат веб-сервера действителен.
Сертификат корневого ЦС установлен в клиентской операционной системе.
Браузер или HTTPS-клиент содержит допустимый корневой сертификат. У Firefox и других браузеров могут быть особые политики сертификации.
Тип назначения URL-адреса в правиле приложения охватывает правильный путь и любые другие гиперссылки, внедренные на странице HTML назначения. Вы можете использовать подстановочные знаки, чтобы упростить охват всего необходимого URL-пути.