Работа с сертификатами в NGFW 7.1.x

В данной статье рассматриваются примеры настройки сертификатов для работы в NGFW 7.1.x для инспектирования SSL, Captive-портала и аутентификации через сертификаты в режиме PKI. Все команды предполагают использование Linux-системы.

Для разных режимов работы с трафиком в NGFW требуются разные типы сертификатов. В этой статье рассматриваются различные режимы работы NGFW и свойства, которыми должны обладать сертификаты для использования в этих режимах.

В версии NGFW 7.1.x. для использования сертификатов в аутентификации создан новый тип профилей — профиль клиентского сертификата. В нём определяется, какие сертификаты входят в цепочку доверия при проведении аутентификации. Конкретный профиль добавляется в соответствующий объект, где нужна аутентификация через сертификат: Captive-портал, правила reverse-прокси и так далее.

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

Термины и обозначения

Сертификат / Certificate

Сертификат, он же X.509-сертификат — стандартизированный бинарный документ или файл, удостоверяющий подлинность веб-сайта, личности пользователя или какой-нибудь другой информации. У владельца сертификата имеется секретный закрытый ключ, которым он может создавать цифровые подписи данных, а в сертификате находится открытая часть этого ключа, позволяющая проверить цифровую подпись.

X.509-сертификаты образуют иерархию/цепочку доверия, когда сертификат более высокого уровня подтверждает своей цифровой подписью достоверность сертификата нижнего уровня. Каждый сертификат включает в себя содержательную часть (формализованные структурированные данные типа названия веб-сайта или допустимых режимов применения сертификата), открытый ключ (public key) сертификата и цифровую подпись, созданную вышестоящим сертификатом для содержательной части и открытого ключа. Закрытый ключ (private key) сертификата хранится отдельно и не должен никогда публиковаться.

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

Самый верхний сертификат в цепочке доверия подписан собственным закрытым ключом (самоподписанный сертификат) и называется корневым сертификатом (root certificate). В цепочке доверия все сертификаты выше финального должны быть CA-сертификатами (сертификатами удостоверяющего центра — УЦ).

Для идентификации в сертификате используется поле Subject; для идентификации сертификата, которым подписан этот сертификат, используется поле Issuer. Структура у них одинаковая — distinguished name (DN) и это поле уникальным образом идентифицирует сертификат. Поле DN структурированное и может включать данные разных типов: Common name, E-mail, Organization и так далее.

В сертификате есть срок действия — две даты, между которыми он считается действительным.

Удостоверяющий центр / УЦ / Certification Authority / CA

Организация или отдел организации, обладающий возможностью создавать сертификаты. Обычно удостоверяющий центр имеет несколько сертификатов, которые используются для подписывания. Все такие сертификаты принято называть УЦ-сертификатами (CA) или сертификатами удостоверяющего центра.

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

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

Сертификаты удостоверяющих центров, которые подписаны каким-либо другим сертификатом, называются промежуточными или подчинёнными. Любой сертификат, подписанный действующим и не отозванным сертификатом считается действующим.

Отзыв сертификата / Certificate revocation / Список отозванных сертификатов

Удостоверяющий центр ведёт специальный реестр отозванных сертификатов, то есть таких, которые до истечения срока действия были объявлены недействительными. Существует общепринятая схема обращения к таким реестрам и по этой схеме работают, например, браузеры или другие продукты, в том числе NGFW. Список отозванных сертификатов называется CRL (Certificate Revocation List).

Запрос на получение сертификата / Certificate Signing Request / CSR

Сертификат создаётся удостоверяющим центром на основе запроса на получения сертификата (CSR). По сути CSR — это тот же сертификат, только подписанный тем же закрытым ключом, открытая часть которого включена в сертификат. Удостоверяющий центр проверяет, что цифровая подпись соответствует указанному открытому ключу и создаёт новую цифровую подпись уже собственным закрытым ключом. В процессе генерации сертификата закрытый ключ клиента никогда не покидает безопасное окружение клиента.

Обычно удостоверяющий центр добавляет к данным из CSR свои: идентификатор УЦ, информацию о режимах использования и так далее.

Аутентификация через сертификат / PKI-аутентификация

Способ аутентификации клиента, при котором для верификации клиента используется не логин/пароль, а клиентский сертификат, установленный вместе с закрытым ключом на стороне клиента.

Программное окружение

Для данного примера подразумевается, что используетcя какой-либо вариант ОС Linux с установленным ПО openssl версии 1.1.1 или выше.

Рекомендуется создать отдельный каталог для тестирования и запускать все команды в нём, например:

mkdir ~/usergate-ngfw-certs
cd ~/usergate-ngfw-certs

Сертификаты в режиме инспектирования SSL

Общая схема цепочки сертификатов в режиме инспектирования SSL:

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

Кроме того, финальный сертификат (на рисунке выше это SSL Inspection Certificate) обязательно должен иметь свойство Path Length Constraint не равным нулю, либо совсем его не иметь. Это необходимо для того, чтобы этим сертификатом можно было создать ещё один сертификат, который используется непосредственно для выписывания на каждом из узлов кластера.

Для корректной работы инспектирования корневой сертификат Root CA Certificate должен быть установлен в доверенное хранилище на стороне клиента. А промежуточный сертификат Intermediate CA Certificate должен отправляться в цепочке промежуточных сертификатов.

Создание цепочки сертификатов для инспектирования SSL

В этом разделе будет показан пример, как вручную через команды openssl создать всю цепочку сертификатов для инспектирования.

Сначала создаётся закрытый ключ и сертификат для корневого удостоверяющего центра (Root CA Certificate). Это самоподписанный сертификат, в котором commonName=Root CA Certificate:

openssl ecparam -name prime256v1 -genkey -noout -out root-ca-key.pem

openssl req -config /dev/null -new -x509 -batch -days 365 -key root-ca-key.pem -subj '/C=AQ/CN=Root CA Certificate' -out root-ca-crt.pem

Далее создается закрытый ключ и сертификат для промежуточного сертификата Intermediate CA Certificate:

openssl ecparam -name prime256v1 -genkey -noout -out intermediate-ca-key.pem

openssl req -config /dev/null -new -key intermediate-ca-key.pem -subj '/C=AQ/CN=Intermediate CA Certificate' -out intermediate-ca-csr.pem

openssl req -config /dev/null -copy_extensions none -days 365 -in intermediate-ca-csr.pem -CA root-ca-crt.pem -CAkey root-ca-key.pem -out intermediate-ca-crt.pem -addext 'basicConstraints = critical, CA:true' -addext 'keyUsage = digitalSignature, keyCertSign'

Затем создаётся финальный сертификат (SSL Inspection Certificate), который будет использоваться в NGFW для инспектирования. Это тоже CA-сертификат:

openssl ecparam -name prime256v1 -genkey -noout -out ssl-inspection-ca-key.pem

openssl req -config /dev/null -new -key ssl-inspection-ca-key.pem -subj '/C=AQ/CN=Local SSL Inspection Certificate' -out ssl-inspection-ca-csr.pem

openssl req -config /dev/null -copy_extensions none -days 365 -in ssl-inspection-ca-csr.pem -CA intermediate-ca-crt.pem -CAkey intermediate-ca-key.pem -out ssl-inspection-ca-crt.pem -addext 'basicConstraints = critical, CA:true' -addext 'keyUsage = digitalSignature, keyCertSign'

В итоге были созданы следующие файлы:

Файл	Описание
root-ca-key.pem	Закрытый ключ сертификата корневого УЦ. Используется только для подписывания сертификата Intermediate CA Certificate.
root-ca-crt.pem	Сертификат Root CA Certificate.
intermediate-ca-key.pem	Закрытый ключ промежуточного сертификата Intermediate CA Certificate. Используется только для подписывания SSL Inspection Certificate.
intermediate-ca-crt.pem	Промежуточный сертификат Intermediate CA Certificate.
ssl-inspection-ca-key.pem	Закрытый ключ сертификата SSL Inspection Certificate.
ssl-inspection-ca-crt.pem	Сертификат SSL Inspection Certificate. Используется для инспектирования SSL в NGFW.

Настройка NGFW и браузера для инспектирования SSL

1. В веб-консоли администратора в разделе Настройки ➜ Сертификаты импортировать сертификат для инспектирования и промежуточный сертификата в виде цепочки:

Сертификат для инспектирования и закрытый ключ загружаются в поля Файл сертификата и Приватный ключ соответственно. Промежуточный сертификат загружается в поле Цепочка сертификатов.

Корневой сертификат в цепочку добавлять не нужно.

2. В свойствах импортированного сертификата назначить роль SSL инспектирование:

3. Создать и включить правило SSL инспектирования.

В веб-консоли администратора в разделе Политики безопасности ➜ Инспектирование SSL создаётся новое правило (или включается существующее). Проверяется корректность указания зоны источника и пользователей.

Если теперь на клиентской машине попытаться открыть в браузере любой внешний https-адрес, то отобразится ошибка соединения и предупреждение о некорректном сертификате. Это значит, что инспектирование работает и нужно настроить систему на стороне клиента.

4. Импортировать в клиентскую систему сертификат корневого удостоверяющего центра для инспектирования.

Сертификат root-ca-crt.pem импортируется в хранилище доверенных сертификатов. Это может быть глобальное системное хранилище или отдельное хранилище для браузера Firefox, например. Другие сертификаты добавлять не нужно.

Если теперь попытаться открыть https-адрес, он должен успешно и без ошибок открыться. 

NGFW при включении инспектирования динамически создаёт сертификат для указанного сайта, подписывает его ключом сертификата из файла ssl-inspection-ca-key.pem, после чего добавляет в цепочку сертификатов дополнительный промежуточный сертификат из файла intermediate-ca-crt.pem.

Сертификат для Captive-портала

Общая схема цепочки сертификатов для использования в Captive-портале:

Для пользователя Captive-портал выглядит как обычный сайт с обычным доменом. В данном примере используется доменное имя test.usergate.local. Доменные сертификаты могут выписываться как сторонним удостоверяющим центром, так и удостоверяющим центром самой организации. Эти сертификаты используются для защиты соединения и удостоверения на стороне клиента, что он видит доверенный сайт, например, в браузере.

Корневой удостоверяющий центр (на иллюстрации его сертификат Root CA Certificate) обычно не используется непосредственно для выписывания сертификатов, вместо этого создаётся цепочка из одного или двух подчинённых (промежуточных) сертификатов, имеющих права на выписывание других сертификатов. На иллюстрации это сертификаты Intermediate CA Certificate и Intermediate CA 2 Certificate. При настройке сервера указывается непосредственно доменный сертификат и его закрытый ключ (на схеме Domain certificate), а промежуточные сертификаты указываются в виде дополнительной цепочки. 

Чтобы вся схема работала, на стороне клиента сертификат Root CA Certificate нужно добавить в хранилище доверенных сертификатов. Остальные промежуточные сертификаты в хранилище доверенных добавлять не нужно, они придут вместе с TLS-ответом от сервера и вся цепочка успешно верифицируется.

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

Создание цепочки доменных сертификатов для тестирования

Закрытый ключ и сертификат для корневого удостоверяющего центра (Root CA Certificate) был создан на предыдущем этапе.

Закрытый ключ и сертификат для промежуточного сертификата (Intermediate CA Certificate) также был создан ранее.

Далее создаётся Intermediate CA 2 Certificate, подписанный сертификатом Intermediate CA Certificate:

openssl ecparam -name prime256v1 -genkey -noout -out intermediate-ca-2-key.pem

openssl req -config /dev/null -new -key intermediate-ca-2-key.pem -subj '/C=AQ/CN=Intermediate CA 2 Certificate' -out intermediate-ca-2-csr.pem

openssl req -config /dev/null -copy_extensions none -days 365 -in intermediate-ca-2-csr.pem -CA intermediate-ca-crt.pem -CAkey intermediate-ca-key.pem -out intermediate-ca-2-crt.pem -addext 'basicConstraints = critical, CA:true' -addext 'keyUsage = digitalSignature, keyCertSign'

cat intermediate-ca-crt.pem intermediate-ca-2-crt.pem > domain-chain.pem

Финальный доменный сертификат (Domain Certificate) для домена test.usergate.local подписывается сертификатом Intermediate CA 2 Certificate:

openssl genrsa -out test.usergate.local-key.pem 2048

openssl req -config /dev/null -new -key test.usergate.local-key.pem -subj '/C=RU/CN=Domain certificate' -out test.usergate.local-csr.pem

openssl req -config /dev/null -copy_extensions none -days 365 -in test.usergate.local-csr.pem -CA intermediate-ca-2-crt.pem -CAkey intermediate-ca-2-key.pem -out test.usergate.local-crt.pem -addext 'subjectAltName = DNS:test.usergate.local'

В итоге имеются следующие файлы:

Файл	Описание
domain-chain.pem	Файл цепочки промежуточных сертификатов, содержащий сертификаты из файлов intermediate-ca-crt.pem и intermediate-ca-2-crt.pem.
intermediate-ca-crt.pem	Сертификат промежуточного УЦ Intermediate CA Certificate.
intermediate-ca-key.pem	Закрытый ключ сертификата промежуточного УЦ Intermediate CA Certificate, используется только для подписывания сертификата Intermediate CA 2 Certificate.
intermediate-ca-2-crt.pem	Сертификат промежуточного УЦ Intermediate CA 2 Certificate.
intermediate-ca-2-key.pem	Закрытый ключ сертификата промежуточного УЦ Intermediate CA 1 Certificate, используется непосредственно для подписывания сертификатов доменов.
root-ca-crt.pem	Сертификат корневого УЦ.
root-ca-key.pem	Закрытый ключ сертификата корневого УЦ, используется только для подписывания сертификата Intermediate CA Certificate.
test.usergate.local-crt.pem	Сертификат для домена test.usergate.local.
test.usergate.local-key.pem	Закрытый ключ сертификата для домена test.usergate.local.

Настройка NGFW и браузера для использования домена test.usergate.local в роли Captive-портала

Предполагается, что Captive-портал будет использоваться клиентами из сетевой зоны Trusted.

1. Настроить доменное имя Captive-портала в NGFW.

В веб-консоли администратора в разделе Настройки ➜ Модули необходимо установить параметр Домен Auth Captive-портала в значение test.usergate.local.

NGFW для этого адреса автоматически настроит DNS-резолвинг в корректный адрес для нужной сетевой зоны.

2. Импортировать сертификат в NGFW.

В веб-консоли администратора в разделе Настройки ➜ Сертификаты импортировать сертификат домена и цепочку промежуточных сертификатов:

Так как этот сертификат используется для домена, необходимо также загрузить для него закрытый ключ.

В свойствах импортированного сертификата назначить роль SSL Captive-портала:

3. Импортировать в клиентскую систему сертификат корневого удостоверяющего центра.

В хранилище доверенных сертификатов на клиентской рабочей станции нужно добавить сертификат из файла root-ca-crt.pem. Теперь домен Captive-портала будет открываться с этим сертификатом на рабочей станции без ошибок.

Аутентификация через X.509-сертификаты (PKI-аутентификация)

Общая схема цепочки сертификатов, используемых для аутентификации:

Цель аутентфикации через сертификат — проверить, что на стороне клиента есть соответствующий закрытый ключ, а связанный с ним сертификат проходит проверку через цепочку доверия. Так как проверки происходят на сервере (NGFW), именно там должна настраиваться цепочка доверия.

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

В NGFW поддержка этого режима реализована через профили клиентских сертификатов, где задаются цепочки доверия, правила извлечения имени пользователя из сертификата, использование CRL и другие настройки. Настроенный профиль привязывается к объекту, где требуется аутентификация через сертификаты: профилю Captive-портала, правилу reverse-прокси и так далее.

При планировании аутентификации через сертификаты организация должна выполнить следующие условия:

• Создать инфраструктуру удостоверяющего центра по выпуску сертификатов для пользователей.

• Определиться со схемой идентификации пользователей, то есть каким именно образом в сертификате будет храниться идентифицирующая пользователя строка: в виде логина в commonName или в виде e-mail в расширении Subject Alternative Name.

• Настроить NGFW, чтобы объекты-пользователи соответствовали выбранной на предыдущем этапе схеме.

• Настроить инфраструктуру распределения сертификатов по клиентам.

Создание цепочки сертификатов аутентификации для тестирования

В этом разделе на примере будет показано, как вручную через вызовы команды openssl создать цепочку описанных на иллюстрации сертификатов УЦ для аутентификации. Общая схема здесь примерно такая же, как и для доменных сертификатов, но используются другие имена для сертификатов, чтобы отличать эту цепочку.

Сначала создаётся закрытый ключ и сертификат для корневого удостоверяющего центра Auth Root CA Certificate. Это самоподписанный сертификат, в котором commonName=Auth Root CA Certificate:

openssl ecparam -name prime256v1 -genkey -noout -out root-auth-ca-key.pem

openssl req -config /dev/null -new -x509 -batch -days 365 -key root-auth-ca-key.pem -subj '/C=AQ/CN=Auth Root CA Certificate' -out root-auth-ca-crt.pem

Далее создаются закрытые ключи и сертификаты для двух промежуточных сертификатов:

1. Сначала создаётся ключ и сертификат для Intermediate Auth CA Certificate (используется полная схема с явным созданием CSR и последующим созданием сертификата на основе CSR):

openssl ecparam -name prime256v1 -genkey -noout -out intermediate-auth-ca-key.pem

openssl req -config /dev/null -new -key intermediate-auth-ca-key.pem -subj '/C=AQ/CN=Intermediate Auth CA Certificate' -out intermediate-auth-ca-csr.pem

openssl req -config /dev/null -copy_extensions none -days 365  -in intermediate-auth-ca-csr.pem -CA root-auth-ca-crt.pem -CAkey root-auth-ca-key.pem -out intermediate-auth-ca-crt.pem -addext 'basicConstraints = critical, CA:true' -addext 'keyUsage = digitalSignature, keyCertSign'

2. Создаётся сертификат Auth Sign CA Certificate, подписанный сертификатом Intermediate Auth CA Certificate:

openssl ecparam -name prime256v1 -genkey -noout -out auth-sign-ca-key.pem

openssl req -config /dev/null -new -key auth-sign-ca-key.pem -subj '/C=AQ/CN=Auth Sign CA Certificate' -out auth-sign-ca-csr.pem

openssl req -config /dev/null -copy_extensions none -days 365 -in auth-sign-ca-csr.pem -CA intermediate-auth-ca-crt.pem -CAkey intermediate-auth-ca-key.pem -out auth-sign-ca-crt.pem -addext 'basicConstraints = critical, CA:true' -addext 'keyUsage = digitalSignature, keyCertSign'

Также создаётся отдельный файл с цепочкой всех CA-сертификатов:

cat root-auth-ca-crt.pem intermediate-auth-ca-crt.pem > pki-auth-chain.pem

Далее создаются несколько клиентских сертификатов, использующих разные способы кодирования имени пользователя в содержательной части. Все они будут подписаны сертификатом Auth Sign CA Certificate. Кроме того, все клиентские сертификаты будут упакованы в переносимые PKCS#12-контейнеры, пригодные для дальнейшего импорта в клиентские устройства.

Создание сертификата, в котором логин пользователя user1 хранится в поле commonName (CN):

openssl genrsa -out user1-cn-key.pem 2048

openssl req -config /dev/null -new -key user1-cn-key.pem -subj '/C=RU/CN=user1/O=RnK' -out user1-cn-csr.pem

openssl req -config /dev/null -copy_extensions none -days 365 -in user1-cn-csr.pem -CA auth-sign-ca-crt.pem -CAkey auth-sign-ca-key.pem -out user1-cn-crt.pem -addext 'extendedKeyUsage = clientAuth, emailProtection'

openssl pkcs12 -password pass:1234 -export -out user1-cn.p12 -name 'User1 personal certificate' -in user1-cn-crt.pem -inkey user1-cn-key.pem -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES

Создание сертификата, в котором e-mail пользователя user2@rnk.local записывается в расширении Subject Alternative Name:

openssl genrsa -out user2-email-key.pem 2048

openssl req -config /dev/null -new -key user2-email-key.pem -subj '/C=RU/O=RnK' -out user2-email-csr.pem

openssl req -config /dev/null -copy_extensions none -days 365 -in user2-email-csr.pem -CA auth-sign-ca-crt.pem -CAkey auth-sign-ca-key.pem -out user2-email-crt.pem -addext 'extendedKeyUsage = clientAuth, emailProtection' -addext 'subjectAltName = email:user2@rnk.local'

openssl pkcs12 -password pass:1234 -export -out user2-email.p12 -name 'User2 personal certificate' -in user2-email-crt.pem -inkey user2-email-key.pem -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES

Создание сертификата для администратора веб-консоли. Поскольку у администратора нет привязанных к нему e-mail адресов, сопоставление сертификата и записи в базе идёт только по логину, в данном случае это Admin:

openssl genrsa -out webui-admin-key.pem 2048

openssl req -config /dev/null -new -key webui-admin-key.pem -subj '/C=RU/O=RnK/OU=System Administration/CN=Admin' -out webui-admin-csr.pem

openssl req -config /dev/null -copy_extensions none -days 365 -in webui-admin-csr.pem -CA auth-sign-ca-crt.pem -CAkey auth-sign-ca-key.pem -out webui-admin-crt.pem -addext 'extendedKeyUsage = clientAuth, emailProtection'

openssl pkcs12 -password pass:1234 -export -out webui-admin.p12 -name 'Admin personal certificate' -in webui-admin-crt.pem -inkey webui-admin-key.pem -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES

В итоге имеются следующие файлы, которые будут использоваться для различных сценариев аутентификации для разных подсистем NGFW:

Файл	Описание
root-auth-ca-key.pem	Закрытый ключ сертификата корневного УЦ, используется только для подписывания Intermediate CA Certificate.
root-auth-сa-crt.pem	Сертификат корневого УЦ.
intermediate-ca-key.pem	Закрытый ключ сертификата промежуточного УЦ.
intermediate-ca-crt.pem	Сертификат промежуточного УЦ.
auth-sign-ca-key.pem	Закрытый ключ сертификата УЦ Auth Sign CA Certificate.
auth-sign-ca-crt.pem	Сертификат Auth Sign CA Certificate, который используется для выпуска клиентских сертификатов.
user1-cn-key.pem	Закрытый ключ персонального клиентского сертификата, идентифицируемого по commonName=user1.
user1-cn-crt.pem	Клиентский сертификат с commonName=user1.
user1-cn.p12	PKCS#12-контейнер с клиентским сертификатом и закрытым ключом с commonName=user1 (пароль контейнера: 1234).
user2-email-key.pem	Закрытый ключ персонального клиентского сертификата, идентифицируемого по e-mail user2@rnk.local.
user2-email-crt.pem	Клиентский сертификат для пользователя с e-mail user2@rnk.local.
user2-email.p12	PKCS#12-контейнер с клиентским сертификатом и закрытым ключом с e-mail user2@rnk.local (пароль контейнера: 1234).
pki-auth-chain.pem	Содержит все CA-сертификаты в цепочке доверия (root-ca-crt.pem и intermediate-ca-crt.pem), это необходимо для корректной TLS-верификации.
webui-admin-key.pem	Закрытый ключ персонального клиентского сертификата для администратора с логином Admin.
webui-admin-crt.pem	Клиентский сертификат для администратора с логином Admin.
webui-admin.p12	PKCS#12-контейнер с клиентским сертификатом и закрытым ключом для администратора.

Импорт в NGFW необходимых для аутентификации сертификатов

Чтобы NGFW мог корректно верифицировать клиентский сертификат, ему нужно знать всю цепочку доверия, которая использовалась при создании этого сертификата. Она задаётся следующим образом при импорте нового сертификата в веб-консоли администратора в разделе Настройки ➜ Сертификаты:

Важно! В данном случае загружаются только сертификаты, без закрытых ключей. В поле Файл сертификата загружается сертификат (auth-sign-ca-crt.pem), которым подписаны клиентские сертификаты, а в поле Цепочка сертификатов загружаются целиком остальные сертификаты в цепочке доверия вплоть до самого верхнего самоподписанного (они были записаны в файл pki-auth-chain.pem).

Этот шаг общий для всех режимов работы и один объект-сертификат может использоваться в нескольких профилях клиентских сертификатов.

Настройка NGFW для аутентификации в Captive-портале через сертификаты

1. Настроить на клиентской стороне корректные сертификаты для инспекции TLS и домена Captive-портала.

Чтобы в браузере без ошибок работал переход на Captive-портал, на клиентской машине (или в браузере) необходимо установить корневой сертификат цепочки, которая используется для сертификата инспектирования TLS-трафика. Этот процесс описан в разделе Настройка NGFW и браузера для инспектирования SSL.

Также необходимо установить сертификат для домена Captive-портала, если для этого используется отдельный сертификат. Этот процесс описан в разделе Сертификат для Captive-портала. Также необходимо проверить, что выбранный домен (в данном примере test.usergate.local) корректно распознаётся на клиентских рабочих станциях и преобразуется в правильный IP-адрес.

2. Создать профиль клиентского сертификата (поиск пользователя через login).

Создание профиля клиентских сертификатов, в котором указывается, как именно NGFW должен верифицировать клиентский сертификат:

Проверка CRL отключена (Проверка отозванных сертификатов), так как в данных тестовых сертификатах CRL не задаётся. Если здесь оставить значение по умолчанию (Сертификат пользователя), то аутентификация через сертификат будет отклоняться на уровне TLS-протокола, не доходя даже до проверки пользователя.

В поле Получить имя пользователя из указывается Common-name, в этом случае значение атрибута commonName поля Subject сертификата будет использоваться для поиска пользователя по его логину.

Если в поле Получать имя пользователя из выбрать Subject altname email, то из X.509-расширения сертификата Subject Alternative Name будет извлекаться элемент типа e-mail и по нему будет идти поиск пользователя по адресу электронной почты.

3. Настроить Captive-профиль:

Обязательно выбирается корректный шаблон в поле Шаблон страницы аутентификации, в выбранном на скриншоте шаблоне вместо стандартной формы логина используется одна кнопка Войти с помощью сертификата.

Также необходимо создать пользователя в NGFW с логином user1:

Этот пользователь будет выбран при использовании сертификата из файла user1-cn.p12.

4. Настроить Captive-правило.

Необходимо создать или включить Captive-правило и указать в нём ранее настроенный Captive-профиль:

5. Настроить клиентскую систему для использования сертификата для доступа к Сaptive-порталу.

На клиентской рабочей станции необходимо установить сертификат из PKCS#12-контейнера в файле user1-cn.p12. При импорте нужно указать пароль, с которым был создан контейнер — это 1234. Этот процесс зависит от используемой операционной системы и браузера. Например, для Firefox (на любой операционной системе) клиентский сертификат необходимо добавлять в настройках браузера. А в Windows Edge и Chrome  используют глобальное системное хранилище.

После его установки при попытке зайти на любой сайт должен отобразиться такой экран:

При нажатии на кнопку Войти с помощью сертификата должно открыться окно выбора сертификата, если до этого всё было корректно настроено:

После выбора сертификата пользователь должен зайти с логином user1 и получить доступ к интернету.

Настройка NGFW для аутентификации в веб-портале через сертификаты

В данном примере настраивается аутентификация в веб-портале по сертификату. Соответствующий пользователь будет выбираться через e-mail, а не login.

1. Создать профиль клиентского сертификата (поиск пользователя через e-mail)

Для веб-портала создается новый профиль клиентского сертификата и в нем выбирается режим поиска пользователя через e-mail. Все остальные настройки аналогичны профилю для Captive-портала:

2. Настроить веб-портал.

В окне настроек веб-портала настроить ключевые элементы:

Для работы веб-портала его нужно включить на соответствующей сетевой зоне.

3. Настроить пользователя для работы с веб-порталом.

Ранее был создан сертификат для пользователя с e-mail user2@rnk.local. Нужно создать локального пользователя с таким же адресом:

Необходимо добавить этого пользователя в свойства веб-портала в разделе Глобальный портал ➜ Веб-портал:

4. Настроить клиентскую систему для использования сертификата для доступа к веб-порталу.

На клиентской рабочей станции необходимо установить сертификат из PKCS#12-контейнера в файле user2-email.p12. Здесь всё аналогично импорту сертификата для пользователя user1.

Настройка NGFW и браузера для использования клиентского сертификата для доступа к reverse-прокси

В данном примере будет происходить настройка аутентификации в reverse-прокси по сертификату с определением пользователя по полю сертификата commonName.

Для адреса сервера reverse-прокси будем использован тот же домен (test.usergate.local) и тот же сертификат, который использовался для Captive-портала.

Профиль клиентского сертификата нужно использовать тот же, который был создан в разделе Создать профиль клиентского сертификата (поиск пользователя через login)

Аналогично нужно настроить DNS-резолвинг имени test.usergate.local, чтобы на клиентской машине он распознавался в корректный адрес интерфейса в корректной зоне.

Также в NGFW создаётся пользователь с логином user1.

1. Настроить правило reverse-прокси.

В правиле reverse-прокси в поле Авторизовать по сертификату выбрать режим аутентификации PKI, далее указать профиль клиентского сертификата:

Выбрать пользователей, которым разрешается доступ.

2. Настроить клиентскую систему.

Для клиентской системы всё аналогично настройке для работы Captive-портала:

• Установить клиентский сертификат из файла user1-cn.p12.

• Установить корневой сертификат для домена test.usergate.local из файла root-ca-crt.pem в хранилище доверенных сертификатов.

Настройка NGFW и браузера для использования клиентского сертификата для входа в веб-консоль администратора NGFW

Профиль клиентского сертификата нужно использовать тот же, который был создан в разделе Создать профиль клиентского сертификата (поиск пользователя через login)

1. Настроить веб-консоль.

При использовании сертификата значение из поля commonName сопоставляется с логином администратора, поэтому необходимо проверить, что логин администратора совпадает со значением в сертификате:

Для включения режима нужно в разделе Настройки ➜ Настройки интерфейса в параметре Режим аутентификации веб-консоли выбрать Профиль клиентского сертификата и выбрать собственно профиль:

После сохранения на перестройку конфигурации уйдёт несколько секунд и консоль станет полностью недоступной в браузере — для установки соединения понадобится установленный в системе корректный клиентский сертификат.

2. Настроить клиентскую систему.

Установить клиентский сертификат из файла webui-admin.p12.

Если всё сделано правильно, то при попытке открыть адрес веб-консоли NGFW отобразится окно выбора сертификата:

И после выбора появится дополнительное окно с подтверждением:

Аутентификация через X.509-сертификаты (PKI-аутентификация) с использованием CRL

CRL / Certificate Revocation List / Список отозванных сертификатов — это механизм для оперативного контроля удостоверяющим центром за выпущенными сертификатами. Упрощённо это список сертификатов, которые удостоверяющий центр считает утратившими силу. Например, если закрытый ключ клиентского сертификата был скомпрометирован, то удостоверяющий центр выпускает новую запись об отозванном сертификате.

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

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

Общая схема сущностей для системы УЦ с CRL выглядит следующим образом:

На иллюстрации изображены два разных CRL для двух сертификатов: промежуточного Intermediate Auth2 CA Certificate (CA CRL) и используемого для подписывания клиентских сертификатов, Auth2 Sign CA Certificate (CA Sign CRL).

Создание необходимых файлов: сертификаты, CRL

Все необходимые сертификаты создаются по такой же схеме, как в разделе Аутентификация через X.509-сертификаты (PKI-аутентификация). Кроме того, для проверки CRL необходимо иметь доступный HTTP-сервер, где можно публиковать файлы. Необходимо обратить внимание, что CRL-файлы должны публиковаться только через HTTP.

Закрытый ключ и сертификат для корневого удостоверяющего центра Auth Root CA Certificate был создан в предыдущем разделе.

Далее аналогично создаются закрые ключи и сертификаты для двух промежуточных сертификатов:

1. Сначала для Intermediate Auth2 CA Certificate создаётся ключ и сертификат (используется полная схема с явным созданием CSR и последующим созданием сертификата на основе CSR), также в сертификате указывается URL-адрес CRL:

openssl ecparam -name prime256v1 -genkey -noout -out intermediate-auth2-ca-key.pem

openssl req -config /dev/null -new -key intermediate-auth2-ca-key.pem -subj '/C=AQ/CN=Intermediate Auth2 CA Certificate' -out intermediate-auth2-ca-csr.pem

openssl req -config /dev/null -copy_extensions none -days 365  -in intermediate-auth2-ca-csr.pem -CA root-auth-ca-crt.pem -CAkey root-auth-ca-key.pem -out intermediate-auth2-ca-crt.pem -addext 'basicConstraints = critical, CA:true' -addext 'keyUsage = digitalSignature, keyCertSign, cRLSign' -addext 'crlDistributionPoints = URI:http://192.168.84.2/crl/ca-crl.pem'

2. Создаётся Auth2 Sign CA Certificate, подписанный сертификатом Intermediate Auth2 CA Certificate:

openssl ecparam -name prime256v1 -genkey -noout -out auth2-sign-ca-key.pem

openssl req -config /dev/null -new -key auth2-sign-ca-key.pem -subj '/C=AQ/CN=Auth2 Sign CA Certificate' -out auth2-sign-ca-csr.pem

openssl req -config /dev/null -copy_extensions none -days 365 -in auth2-sign-ca-csr.pem -CA intermediate-auth2-ca-crt.pem -CAkey intermediate-auth2-ca-key.pem -out auth2-sign-ca-crt.pem -addext 'basicConstraints = critical, CA:true' -addext 'keyUsage = digitalSignature, keyCertSign, cRLSign' -addext 'crlDistributionPoints = URI:http://192.168.84.2/crl/casign-crl.pem'

Создаётся отдельный файл с цепочкой всех CA-сертификатов, также в сертификате указываем URL-адрес CRL:

cat root-auth-ca-crt.pem intermediate-auth2-ca-crt.pem > pki-auth2-chain.pem

Далее создаются несколько клиентских сертификатов, во всех сертификатах будет использоваться поле commonName для определения логина пользователя. Все они будут подписаны сертификатом Auth2 Sign CA Certificate, кроме того, все клиентские сертификаты будут упакованы в переносимые PKCS#12-контейнеры, пригодные для дальнейшего импорта в клиентские устройства.

Сертификат для пользователя с логином user1:

openssl genrsa -out user1-auth2-key.pem 2048

openssl req -config /dev/null -new -key user1-auth2-key.pem -subj '/C=RU/CN=user1/O=RnK' -out user1-auth2-csr.pem

openssl req -config /dev/null -copy_extensions none -days 365 -in user1-auth2-csr.pem -CA auth2-sign-ca-crt.pem -CAkey auth2-sign-ca-key.pem -out user1-auth2-crt.pem -addext 'extendedKeyUsage = clientAuth, emailProtection' -addext 'crlDistributionPoints = URI:http://192.168.84.2/crl/casign-crl.pem'

openssl pkcs12 -password pass:1234 -export -out user1-auth2.p12 -name 'User1 personal certificate' -in user1-auth2-crt.pem -inkey user1-auth2-key.pem -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES

Сертификат для пользователя user3:

openssl genrsa -out user3-auth2-key.pem 2048

openssl req -config /dev/null -new -key user3-auth2-key.pem -subj '/C=RU/CN=user3/O=RnK' -out user3-auth2-csr.pem

openssl req -config /dev/null -copy_extensions none -days 365 -in user3-auth2-csr.pem -CA auth2-sign-ca-crt.pem -CAkey auth2-sign-ca-key.pem -out user3-auth2-crt.pem -addext 'extendedKeyUsage = clientAuth, emailProtection' -addext 'crlDistributionPoints = URI:http://192.168.84.2/crl/casign-crl.pem'

openssl pkcs12 -password pass:1234 -export -out user3-auth2.p12 -name 'User3 personal certificate' -in user3-auth2-crt.pem -inkey user3-auth2-key.pem -keypbe PBE-SHA1-3DES -certpbe PBE-SHA1-3DES

Для работы с CRL потребуется создать конфигурационные файлы для двух CRL. Файл openssl-casign-crl.conf создается следующей командой:

cat <<EOF > openssl-casign-crl.conf
[ ca ]
default_ca	= CA_default	
[ CA_default ]
database = ./casign_crl_index.txt
crlnumber = ./casign_crl_number
default_days = 365
default_crl_days = 30
default_md = default
preserve = no
EOF

Файл openssl-ca-crl.conf создается следующей командой:

cat <<EOF > openssl-ca-crl.conf
[ ca ]
default_ca	= CA_default	
[ CA_default ]
database = ./ca_crl_index.txt
crlnumber = ./ca_crl_number
default_days = 365
default_crl_days = 30
default_md = default
preserve = no
EOF

Создаются файлы базы данных CRL (в них хранится версия CRL) и первые пустые CRL:

touch ./casign_crl_index.txt ./ca_crl_index.txt

echo 00 > casign_crl_number

echo 00 > ca_crl_number

openssl ca -config openssl-ca-crl.conf -gencrl -keyfile intermediate-auth2-ca-key.pem -cert intermediate-auth2-ca-crt.pem -out ca-crl.pem

openssl ca -config openssl-casign-crl.conf -gencrl -keyfile auth2-sign-ca-key.pem -cert auth2-sign-ca-crt.pem -out casign-crl.pem

CRL пока пустые, позднее в них будут добавлены записи об отзыве сертификатов. Оба файла нужно опубликовать по URL, указанным в соответствующих сертификатах. Для данного примера это:

• ca-crl.pem → http://192.168.84.2/crl/ca-crl.pem

• casign-crl.pem → http://192.168.84.2/crl/casign-crl.pem

Посмотреть содержимое CRL casign-crl.pem можно командой:

openssl crl -in casign-crl.pem -noout -text

В итоге имеются следующие файлы:

Файл	Описание
root-auth-ca-key.pem	Закрытый ключ сертификата корневного УЦ.
root-auth-ca-crt.pem	Сертификат корневого УЦ.
intermediate-auth2-ca-key.pem	Закрытый ключ сертификата промежуточного УЦ Intermediate Auth2 CA Certificate, им подписывается сертификат УЦ auth2-sign-ca-crt.pem, а также CRL ca-crl.pem.
intermediate-auth2-ca-crt.pem	Сертификат промежуточного УЦ Intermediate Auth2 CA Certificate.
auth2-sign-ca-key.pem	Закрытый ключ сертификата промежуточного УЦ Auth2 Sign CA Certificate, им подписываются клиентские сертификаты и CRL casign-crl.pem.
auth2-sign-ca-crt.pem	Сертификат промежуточного УЦ Auth2 Sign CA Certificate.
ca-crl.pem	CRL для сертификата УЦ Intermediate Auth2 CA Certificate.
casign-crl.pem	CRL для сертификата УЦ Auth2 Sign CA Certificate, в него должны добавляться записи об отозванных клиентских сертификатах.
user1-auth2-key.pem	Закрытый ключ персонального клиентского сертификата, идентифицируемого по commonName=user1.
user1-auth2-crt.pem	Клиентский сертификат с commonName=user1.
user1-auth2.p12	PKCS#12-контейнер с клиентским сертификатом и закрытым ключом с commonName=user1 (пароль контейнера: 1234).
user3-auth2-key.pem	Закрытый ключ персонального клиентского сертификата, идентифицируемого по commonName=user3.
user3-auth2-crt.pem	Клиентский сертификат с commonName=user3.
user3-auth2.p12	PKCS#12-контейнер с клиентским сертификатом и закрытым ключом с commonName=user3 (пароль контейнера: 1234).

Создание пользователей

В NGFW необходимо создать пользователей с логинами user1 и user3.

Импорт в NGFW необходимых сертификатов

В NGFW загружается сертификат из файла auth2-sign-ca-crt.pem, в качестве цепочки промежуточных сертификатов загружается intermediate-auth2-ca-crt.pem. Закрытые ключи загружать не нужно.

Настройка NGFW для аутентификации в Captive-портале через сертификаты с поддержкой CRL

1. Настроить домен и сертификаты.

Настройка аналогична ранее описанной в разделе Настроить на клиентской стороне корректные сертификаты для инспекции TLS и домена Captive-портала

2. Создать профиль клиентского сертификата (выбор пользователя через login, поддержка CRL)

Создаётся профиль клиентского сертификата, в котором указывается, как именно NGFW должен верифицировать клиентский сертификат. Настройка аналогична ранее описанной в разделе Создать профиль клиентского сертификата (поиск пользователя через login), только в данном случае включается использование CRL:

3. Настроить Captive-профиль (CRL).

Настройка аналогична описанной в разделе Настроить Captive-профиль, только в поле Профиль сертификата пользователя выбрать профиль Captive portal auth certificate profile (CRL).

Плюс необходимо создать локального пользователя с логином user3.

4. Настроить Captive-правило (CRL).

Настройка аналогична описанной в разделе Настроить Captive-правило.

5. Настроить клиентскую систему для использования сертификата для доступа к Captive-порталу (CRL).

На клиентской рабочей станции необходимо установить сертификаты из PKCS#12-контейнеров в файлах user1-auth2.p12 и user3-auth2.p12. У всех контейнеров пароль 1234.

Если всё сделано правильно, должен быть успешный вход при помощи любого из этих двух сертификатов:

Отзыв клиентского сертификата

1. Создать CRL для отозванного сертификата пользователя user3.

Для примера отозвать сертификат пользователя user3. Первым этапом необходимо обновить базу отозванных сертификатов:

openssl ca -config openssl-casign-crl.conf -revoke user3-auth2-crt.pem -keyfile auth2-sign-ca-key.pem -cert auth2-sign-ca-crt.pem

Эта команда обновляет только базу (файл casign_crl_index.txt и другие), для генерации CRL в файле casign-crl.pem необходимо выполнить команду:

openssl ca -config openssl-casign-crl.conf -gencrl -keyfile auth2-sign-ca-key.pem -cert auth2-sign-ca-crt.pem -out casign-crl.pem

Теперь в файле casign-crl.pem есть запись об отозванном сертификате, файл необходимо выложить на сервер, чтобы он стал доступен по адресу http://192.168.84.2/crl/casign-crl.pem

2. Проверить, что отозванный сертификат нельзя использовать для аутентификации пользователя user3.

Нужно дождаться, чтобы NGFW скачал файл casign-crl.pem и обновил в своей базе список отозванных сертификатов. Далее необходимо сделать попытку залогиниться из браузера через сертификат пользователя user3. В браузере появится следующее сообщение:

Отзыв промежуточного сертификата

1. Сгенерировать CRL для промежуточного сертификата Auth2 Sign CA Certificate.

Промежуточный сертификат — это сертификат Auth2 Sign CA Certificate, в нём указан адрес CRL Distribution Point http://192.168.84.2/crl/ca-crl.pem. Необходимо обновить базу отозванных сертификатов и отозвать сертификат Auth2 Sign CA Certificate (это делается с помощью ключа сертификата Intermediate Auth2 CA Certificate):

openssl ca -config openssl-ca-crl.conf -revoke auth2-sign-ca-crt.pem -keyfile intermediate-auth2-ca-key.pem -cert intermediate-auth2-ca-crt.pem

Для генерации CRL выполняется команда:

openssl ca -config openssl-ca-crl.conf -gencrl -keyfile intermediate-auth2-ca-key.pem -cert intermediate-auth2-ca-crt.pem -out ca-crl.pem

2. Проверить, что отозванный сертификат нельзя использовать для аутентификации пользователя user1

Нужно дождаться, чтобы NGFW скачал файл ca-crl.pem и обновил в своей базе список отозванных сертификатов. В данном примере будет использован пользователь user1, чтобы проверка на отозванный сертификат сработала выше по цепочке доверия на сертификате, которым подписан клиентский сертификат.

В браузере отобразится сообщение, аналогичное сообщению в предыдущем разделе: