Share via

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

Certificate process

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

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

  • При развертывании в качестве секрета 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 Firewall Premium overview diagram

Важно!

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

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

Если вы хотите создать собственные сертификаты, для упрощенной проверки 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.

Screenshot showing auto-generated certificates.

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

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

  • Сертификат веб-сервера действителен.

  • Сертификат корневого ЦС установлен в клиентской операционной системе.

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

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

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