Если вы планируете разрешить удаленным пользователям аутентифицироваться с помощью клиентских 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 |