Аутентификация клиентскими SSL сертификатами и 2-х факторная аутентификация

WEB-приложение Сведение отчетности (29.04.2026) | (одним файлом) (cсылка)
Аутентификация клиентскими SSL сертификатами и 2-х факторная аутентификация
Если вы планируете разрешить удаленным пользователям аутентифицироваться с помощью клиентских SSL сертификатов, либо разрешить 2-х факторную аутентификацию с использованием SSL сертификатов пользователей, то установите соответствующие флажки. Публично доступный URL текущего сервиса, включая порт, если он нестандартный:Укажите URL, по которому пользователи будут входить на сайт (так называемая "точка входа" для пользователя), обычно это сам домен сервиса. На этом URL у пользователя не будет запрашиваться его SSL сертификат, он будет работать на порту, который указан на странице Параметры сетевых настроек - Настройки протокола HTTPS, обычно это порт умолчанию 443.
Важно! | Если сервис доступен пользователю по нестандартном порту (отличному от 443), то в текущем параметре обязательно требуется указать URL вместе с этим нестандартным портом. Доступность сервиса для пользователя на нестандартном порту, может быть по разным причинам, например: - при конфигурации указан нестандартный порт на странице Параметры сетевых настроек - Настройки протокола HTTPS - сервис работает за серверным прокси, который использует нестандартный порт - сервис работает за пробросом портов (port forwarding) и порт для "входа" нестандартный
Порт дополнительного прослушивателя, для запроса сертификата пользователя: Укажите порт, на который будут автоматически перенаправляться пользователи для прохождения аутентификации по SSL сертификату (в случае аутентификации по SSL сертификату, сразу после того как пользователь инициирует авторизацию, а в случае 2-х факторной аутентификации, после того как пользователь пройдет аутентификацию по логин/паролю). На этом порту (итоговый URL складывается из значения вышеуказанного параметра Публично доступный URL текущего сервиса + указанный Порт дополнительного прослушивателя, из текущего параметра, по приведенному примеру, URL получится следующим - https://balance.ru:4443) у пользователя будет запрашиваться его клиентский SSL сертификат, другими словами, будет попытка установить соединение с взаимной проверкой и клиента и сервера (mutual TLS или mTLS). После того как пользователь укажет свой сертификат, он будет проверяться на веб сервере (сначала на доверие, по нижеуказанным параметрам, а потом на соответствие сертификата пользователю в Парус). Сертификаты доверенных центров сертификации: Укажите путь к файлу в PEM-формате, содержащий публичный сертификат доверенного центра сертификации, по которому будут проверяться клиентские сертификаты - они выпущены им или нет. Клиентские сертификаты могут быть выпущены не только напрямую указанным центром, но и его дочерними центрами, а также и их дочерними, в свою очередь. Каждый такой промежуточный центр сертификации считается доверенным на том основании, что он выпущен доверенным корневым центром. Соответственно, нет необходимости включать их (промежуточные центры) в файл доверенных центров сертификации. При проверке пользовательского сертификата, каждый такой промежуточный центр, увеличивает глубину проверки в цепочке сертификатов на 1. Важно, чтобы итоговая глубина проверки не превышала указанного значения в нижеописанном параметре Глубина проверки в цепочке сертификатов. В случае необходимости доверять нескольким центрам сертификации, их сертификаты можно сохранить в один файл, в котором расположить их друг за другом, т.е. обычной конкатенацией и с новой строки.
Кстати | Указанные сертификаты в параметре "Сертификаты доверенных центров сертификации" влияют на показываемый пользователю список клиентских сертификатов для выбора - показываются только те сертификаты, которые выпущены указанными центрами сертификации. Т.е. указанный список, при установке соединения, передается с сервера на клиент, и далее, браузер корректирует список сертификатов для выбора, перед тем как показать его пользователю. Таким образом, косвенно через этот список, управляется выбор сертификатов для пользователя, в частности, показывать только RSA или только ГОСТ.
Список отозванных сертификатов: При необходимости, укажите путь к файлу в PEM-формате, содержащий отозванные сертификаты (признаваемые недействительными раньше срока своего окончания).
Кстати | Получение CRL файла в PEM формате. Если используется собственный центр сертификации на основе инфраструктуры OpenSSL:
    openssl ca -gencrl -out ca.crl
В результате будет сформирован CRL файл в PEM формате, содержащий список отозванных сертификатов на основе данных внутреннего хранилища сертификатов OpenSSL. В случае использования клиентских сертификатов полученных от стороннего центра сертификации, необходимо получить URL по которому можно скачать CRL файл данного центра сертификации. Данный URL обычно присутствует в любом из публичных сертификатов. Просмотр с помощью OpenSSL, при условии, что файл сертификата в PEM формате (в примере просматривается сертификат c:\ca.pem):
    openssl x509 -noout -text -in c:\ca.pem
Среди всех свойств сертификата найти с именем X509v3 CRL Distribution Points - в нем будет указано необходимое значение URI:http://... Просмотр с помощью средств Windows (файл сертификата может быть в любом формате, но должен иметь расширение.crt): Открываем файл сертификата в проводнике В открывшемся диалоге свойств сертификата переходим на вкладку Details Среди свойств сертификата выбираем CRL Distribution Points Копируем URL из значения этого свойства После скачивания CRL файла по полученному URL, его необходимо сконвертировать в PEM формат (в примере исходный файл в DER формате - crl.der, итоговый файл в PEM формате - crl.pem):
    openssl crl -inform DER -in crl.der -outform PEM -out crl.pem
Получение данных CRL файла, и его конвертацию в PEM-формат необходимо автоматизировать и перезаписывать указанный в текущем параметре файл, чтобы веб сервер мог вычитывать из него актуальные сведения об отозванных сертификатах пользователей.
Глубина проверки в цепочке сертификатов: Укажите глубину проверки в цепочке сертификатов. Глубина проверки устанавливает лимит на количество сертификатов между конечным сертификатом пользователя и доверенным центром, находящимся в файле доверенных центров сертификации. Если цепочка сертификатов, необходимая для получения доверенного эмитента, длиннее указанной глубины + 2, то пользовательский сертификат будет признан недействительным.
Важно! | Как осуществляется проверка клиентского сертификата. На каждом уровне проверки цепочки сертификата проверяется действительность этого сертификата. Если будет обнаружен хоть 1 просроченный, недействительный, не доверенный сертификат (отсутствует связь с сертификатами из файла доверенных центров сертификации) или отозванный (присутствующий в файле Список отозванных сертификатов), или будет превышена указанная глубина проверки, то сам пользовательский сертификат также будет считаться недействительным.
Использовать другой сертификат вместо указанного в настройках HTTPS: Если данная опция выключена, то на Порту дополнительного прослушивателя, для запроса сертификата пользователя будут использоваться те же настройки, что указаны на странице Параметры сетевых настроек - Настройки протокола HTTPS. А если опция включена, то дополнительный порт можно настроить независимо от основного прослушивателя. Эта опция дает возможность гибко разделить использование сертификата для основного прослушивателя (функционирование сервиса по HTTPS протоколу) и использование сертификата для проверки клиентских SSL сертификатов (в дополнительном прослушивателе). Т.к. проверка клиентских сертификатов на основе RSA алгоритмов, предполагает использование RSA сертификата на дополнительном прослушивателе со стороны сервера. И аналогично, в случае необходимости проверки клиентских сертификатов на основе ГОСТ алгоритмов, требует использования ГОСТ сертификата на дополнительном прослушивателе со стороны сервера. В частности, при необходимости проверять сертификаты пользователей с ГОСТ алгоритмами, логично было бы настроить: - сам сайт сервиса (главная страница, точка входа пользователей, основной прослушиватель) на работу с RSA сертификатом (не ГОСТ). Это позволит добиться его доступности и поддержки со стороны всех браузеров. - а URL (с портом дополнительного прослушивателя), на котором будет требоваться сертификат клиента (осуществляться mTLS) на работу с ГОСТ сертификатом. Для этого, со стороны клиента, будет необходим браузер, поддерживающий ГОСТ шифрование (Chromium Gost, Яндекс Браузер, и другие). Таким образом, такое разделение позволит снять необходимость использования специального браузера для тех пользователей, которым не требуется авторизовываться клиентскими ГОСТ сертификатами. Для этого, включите текущий параметр и укажите данные ГОСТ сертификата для дополнительного прослушивателя. По смыслу, функциональность параметров (Сертификат центра сертификации, Сертификат домена, Закрытый ключ, Пароль закрытого ключа, Набор шифров для TLS 1.2- и Набор шифров для TLS 1.3+) полностью соответсвует описанию на странице Параметры сетевых настроек - Настройки протокола HTTPS.
Важно! | Не забудьте указать набор шифров для поддержки ГОСТ алгоритмов в параметрах Набор шифров для TLS 1.2 и ранее и Набор шифров для TLS 1.3+. Перед настройкой необходимо иметь 2 валидных сертификата, валидирующих один и тот же домен (указанный в параметре "Публично доступный URL текущего сервиса"). Допустим это будет balance.ru, тогда необходимо подготовить: 1) RSA сертификат для главной страницы, валидирующий домен balance.ru 2) ГОСТ сертификат для прослушивателя дополнительного порта, где будет запрашиваться сертификат пользователя, валидирующий тот же домен balance.ru