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