Если вы планируете разрешить удаленным пользователям аутентифицироваться с помощью клиентских 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-формате, содержащий публичные сертификаты доверенных центров сертификации, которые будут использоваться для проверки клиентских сертификатов. Клиентские сертификаты могут быть выпущены как напрямую указанным доверенным центром(ами), так и его дочерними центрами, при условии, что вся цепочка сертификатов корректно строится (ведёт к одной из точек доверия) и успешно валидируется.

Сервер будет считать доверенными только те сертификаты, которые явно указаны в этом файле как точки доверия (trust anchors). По умолчанию, точками доверия являются все корневые сертификаты любого центра сертификации, включенные в этот файл. Промежуточные сертификаты, включенные в этот файл, не считаются автоматически доверенными (они будут использоваться только для построения цепочки, т.е. просто как известные серверу сертификаты), если только администратор явно не настроил их как точки доверия.
Подробнее о принципах проверки и как сделать промежуточный сертификат точкой доверия, описано в статье Принцип проверки клиентских сертификатов (mTLS).

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

Пример

Чтобы расположить в файле несколько сертификатов, нужно просто их туда вставить (один за одним, с новой строки), как в текстовый файл: -----BEGIN CERTIFICATE----- ...  -----END CERTIFICATE----- -----BEGIN TRUSTED CERTIFICATE----- ...  -----END TRUSTED CERTIFICATE----- и т.д.

Кстати

Указанные сертификаты в параметре "Сертификаты доверенных центров сертификации" влияют на показываемый пользователю список клиентских сертификатов для выбора - показываются только те сертификаты, которые выпущены указанными центрами сертификации. Т.е. указанный список, при установке соединения, передается с сервера на клиент, браузер получив этот список, отфильтровывает по нему список имеющихся сертификатов для выбора (отбирает только те, что выданы этими ЦС), перед тем как показать его пользователю. Таким образом, косвенно через этот список, управляется выбор сертификатов для пользователя, в частности, показывать только 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 протокола для дополнительного порта, можно настроить независимо от основного прослушивателя.

Эта опция дает возможность гибко разделить использование сертификата для основного прослушивателя (функционирование сервиса по 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

Аутентификация клиентскими SSL сертификатами, включая 2-х факторную аутентификацию использующую SSL сертификаты, основана на mTLS (mutual TLS) -проверка сервером клиентских сертификатов, в процессе SSL рукопожатия (handshake), сразу после установки TCP соединения.

Проверка клиентских сертификатов выполняется с использованием OpenSSL. Все правила, описанные в документации OpenSSL для проверки сертификатов (https://docs.openssl.org/master/man1/openssl-verification-options/), применимы и к данному ПП.

Хранилище доверенных сертификатов(trust store)

Для проверки клиентских сертификатов используется хранилище доверенных сертификатов (в документации OpenSSL - trust store). В это хранилище сертификаты попадают только из файла, указанного при конфигурации в поле "Сертификаты доверенных центров сертификации". Файл может содержать один или несколько сертификатов, порядок их расположения в файле не важен.

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

Точки доверия (trust anchors)

Все сертификаты, попавшие в хранилище доверенных сертификатов, автоматически разделяются на две категории:

• Точки доверия (trust anchors): могут являться конечными сертификатами цепочки - построение цепочки всегда останавливается на них, и они воспринимаются как "корневые", в рамках проверки цепочки клиентского сертификата
• Остальные сертификаты: все остальные сертификаты не ставшие точками доверия, обычно это сертификаты промежуточных центров сертификации - при построении цепочки они используются просто как известные серверу сертификаты

По умолчанию, точками доверия становятся все корневые сертификаты центров сертификации, т.е. самоподписанные, а не выпущенные кем-то - они физически и являются конечными корневыми сертификатами.

Администратор может принудительно назначить любой промежуточный сертификат в качестве точки доверия (trust anchor), т.е. вручную перевести сертификат из категории Остальные сертификаты в Точки доверия. В этом случае, построение цепочки клиентского сертификата будет останавливаться на этом промежуточном сертификате, считая его корневым, даже если до настоящего корня, выше выбранного, могут быть ещё сертификаты (в том числе неизвестные серверу или просроченные).

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

Чтобы вручную пометить сертификат как точку доверия, перед его добавлением в PEM‑файл, необходимо выполнить команду OpenSSL:

openssl x509 -in c:\cert.pem -addtrust clientAuth -out c:\trusted.pem

где:
  - c:\cert.pem - входной файл с одним сертификатом
  - c:\trusted.pem - выходной файл, в котором указанный сертификат будет помечен как доверенный, в терминологии OpenSSL такой сертификат получает positive trust attribute для цели clientAuth.

После успешного выполнения команды содержимое выходного файла можно добавить в итоговый PEM-файл, который будет указан при конфигурации в поле "Сертификаты доверенных центров сертификации". Если требуется сделать точками доверия несколько сертификатов, то нужно повторить процедуру для каждого из них.

Работа сервиса

Построение цепочки клиентского сертификата

При установке соединения, в котором клиент должен представиться серверу (mTLS), а сервер проверить предоставленный клиентский сертификат - клиент обязан прислать всю цепочку сертификатов за исключением корневого. т.е. он отправит свой клиентский сертификат + все промежуточные сертификаты. При работе через браузеры, это гарантировано - браузеры, при mTLS всегда так действуют и это нельзя выключить.

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

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

Проверка построенной цепочки

После успешного построения цепочки сервер выполняет её валидацию, для этого каждый сертификат проверяется:

• проверяется период действия сертификата относительно текущего системного времени на сервере
• проверяется отсутствие сертификата в списках отозванных (CRL)
• для корневого сертификата построенной цепочки (точки доверия) обязательно проверяется его наличие в хранилище доверенных сертификатов

Отдельно контролируется длина цепочки, не превышает ли она значение указанное в конфигураторе, в поле "Глубина проверки в цепочке сертификатов". В OpenSSL умолчание для глубины = 100, но в ПП умолчание сейчас = 1. В подсчете длины цепочки не участвует сам сертификат клиента (можно сказать, что он номер 0) и корневой сертификат построенной цепочки, т.е. считаются только промежуточные сертификаты.
Если фактическая глубина цепочки превышает заданный максимум, проверка клиентского сертификата завершается ошибкой и сертификат клиента признается невалидным.