PayControl PKI

Введение

Документ описывает процесс выпуска сертификатов открытых ключей пользователей PayControl и процесс формирования CMS-подписи.

С версии 5.2 PayControl может выпускать сертификаты для пользователей с помощью OpenSSL, с версии 6.9 — имеет интеграцию c КриптоПро УЦ 2.0 (исполнение 15, 16).

Описание параметров конфигурации коннекторов к УЦ доступно в статье по ссылке https://repo.paycontrol.org/wiki/index.php/PayControl_PKI.

Выпуск сертификата

Ниже описан процесс от создания пользователя PayControl и выпуск сертификата.

Предварительные условия

  • PCS должен быть настроен на работу с УЦ.

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

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

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

Процесс создания пользователя и выпуска сертификата

Примечания к диаграмме

  • Вызов эндпоинта создания сертификата: PCS проверяет, был ли ранее выпущен сертификат для этого открытого ключа пользователя. Если уже есть действующий сертификат, процесс выпуска прекращается с ошибкой 354 (CERTIFICATE_IS_NOT_UNIQUE), см. раздел Errors в PC API Reference.
  • Повторный выпуск сертификата открытого ключа: PC позволяет создать повторный запрос на выпуск сертификата открытого ключа, если сертификат ранее уже выпускался, но в настоящее время нет действующих сертификатов. Однако, в зависимости от политик УЦ, в нём может быть запрещена повторная выдача сертификатов открытого ключа.
  • Certificate request info — содержательная часть запроса на сертификат в соответствии со стандартом PKCS#10, но без электронной подписи. Формируется на стороне PCS.
  • Certificate request (CSR) — готовый (содержащий ЭП) запрос на сертификат в соответствии со стандартом PKCS#10.

Формирование ЭП в формате CMS

PC позволяет формировать откреплённую (detached) CMS-подпись — это CMS/PKCS#7 контейнер SignedData, в котором подписываемые данные не вкладываются внутрь контейнера, а подпись вычисляется по внешнему содержимому (обычно по его байтам или хэшу).

Ниже показан процесс формирования подписи и последующей проверки.

Процесс формирования CMS-подписи

Примечания к диаграмме

  • Для выработки подписи в формате CMS — должен быть явно указан тип создаваемой транзакции "CMS".
  • Проверка наличия зарегистрированного ключа: при создании CMS-транзакции сервер сначала проверяет, зарегистрирован ли открытый ключ пользователя. Если нет, процесс завершается с ошибкой 276 (PUBKEY_IS_EMPTY).
  • Проверка наличия действующего сертификата: затем сервер проверяет по своей базе, есть ли у пользователя действующий сертификат (статус CERT_ISSUED). Если корректного действующего сертификата нет, процесс создания CMS-транзакции прекращается с соответствующей ошибкой (например, нет сертификата, или он отозван, и т.д.).
  • Проверка что сертификат не отозван: сервер проверяет не отозван ли сертификат по спискам отзыва/OCSP. Если сертификат отозван, то статус сертификата меняется на сервере на CERT_REVOKED.
  • Authenticated attributes — данные, для которых вычисляется ЭП, в соответствии со стандартом PKCS#7. Формируется на стороне сервера PC.