Pkcs10 криптопро и Криптографические ресурсы

Активация выпущенного сертификата

Ресурс /v1/crypto/cert-requests/{externalId}/activate позволяет создавать запросы на активацию выпущенного сертификата, для дальнейшей возможности подписывать документы и запросы.

Шаги

1. При авторизации передать в scope сервис CERTIFICATE_REQUEST.

2. Отправить POST-запрос (/v1/crypto/cert-requests/{externalId}/activate) с Access Token и идентификатором запроса на сертификат externalId. Access token передается в параметре Authorization заголовка запроса.

Модель запроса

Пример запроса

curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json'--header'Authorization: Bearer daf9a14c-821d-4bde-9c10-0e56e63d54a0-1'

Получение печатной формы сертификата

Ресурс /v1/crypto/cert-requests/{externalId}/print позволяет получить печатную форму сертификата.

Шаги

1. При авторизации передать в scope сервис CERTIFICATE_REQUEST.

2. Отправить GET-запрос (/v1/crypto/cert-requests/{externalId}/print) с Access Token и идентификатором запроса на сертификат externalId. Access token передается в параметре Authorization заголовка запроса.

Модель запроса

Пример запроса

curl -X GET --header `Accept: /` --header`Authorization: Bearer f8ad3141-b7e8-4924-92de-3de4fd0a464e-1`

Совместимые реализации X. 509 и CMS с использованием российских алгоритмов

На настоящий момент проведены испытания на соответствие техническим спецификациям и возможности встречной работы следующих СКЗИ:

• СКЗИ “Валидата CSP 5.0” (ООО “Валидата”) и СКЗИ “КриптоПро CSP 4.0” (ООО “КРИПТО‑ПРО”), испытания завершены, см. протокол испытаний [validata-csp];
• СКЗИ “МагПро КриптоПакет 3.0” (ООО “Криптоком”) и СКЗИ “КриптоПро CSP 4.0” (ООО “КРИПТО‑ПРО”), испытания завершены, см. протокол испытаний [magpro].

Этот список будет расширяться по мере проведения тестовых испытаний.

Подготовительный шаг

Нам понадобится:

1. OpenSSL
2. Stunnel
3. rtengine
4. Доступ к тестовым серверам КриптоПро, для проверки соединения по TLS

OpenSSL для Windows можно взять отсюда, а для пользователей линукса — из репозиториев или собрать самому, скачав свежую версию отсюда. Также его можно взять из Rutoken SDK, из директории openssl\openssl-tool-1.1, этот архив нам будет полезен и дальше, т.к. в нём находится интересующий нас rtengine. Stunnel можно найти здесь. Для работы необходима версия >= 5.56.

Скачать rtengine можно из Rutoken SDK, он лежит в директории openssl\rtengine\bin. Закинуть его нужно туда, где хранятся все движки openssl. Узнать путь до них можно с помощью

openssl.exe version -a

Но просто переместить движок в нужную папку — мало, нужно ещё сконфигурировать сам openssl для работы с ним. Узнаём где лежит файл с конфигурацией openssl.cnf с помощью той же команды, что указана выше (под виндой stunnel идёт с собственной версией openssl, поэтому файл с конфигурацией лежит в path\to\stunnel\config\openssl.cnf

# В начале напишем:
openssl_conf = openssl_def

...

# В конце файла:
# OpenSSL default section
[openssl_def]
engines = engine_section

[engine_section]
rtengine = gost_section

[gost_section]
dynamic_path = /path/to/rtengine.so
MODULE_PATH = /usr/lib/librtpkcs11ecp.so
default_algorithms = CIPHERS, DIGEST, PKEY, RAND

Давайте проверим, что rtengine подключился, для этого подключим токен и выведем список всех алгоритмов шифрования:

openssl ciphers -v

Напомню, что в Windows нужно проверять на openssl, который лежит рядом с stunnel
Если среди них будут присутствовать наши ГОСТы, значит всё настроено верно.

Настало время самого интересного: проверка установки соединения по ГОСТу с тестовыми серверами КриптоПро. Список данных серверов описан здесь (https://www.cryptopro.ru/products/csp/tc26tls). Каждый из этих серверов работает со своими алгоритмами для аутентификации и шифрования. Более того на портах 443, 1443, 2443,… запущены сервисы, которые воспринимают только определённые парамсеты. Так, например, по адресу http://tlsgost-256auth.cryptopro.ru происходит шифрование с аутентификацией с использованием алгоритмов GOST2012-GOST8912-GOST8912 и 256-битным ключом. Так же на порту 443 используется XchA-ParamSet, на порту 1443 — XchB-ParamSet, на порту 2443 — A-ParamSet и т.д.

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

Простой способ (работает под Windows и Linux)

1. Для того, чтобы получить корневой сертификат, зайдём на сайт тестового УЦ ООО “КРИПТО-ПРО”. И нажмём на кнопку для получения сертификата. Отобразится новая вкладка, на которой нужно будет выбрать метод шифрования Base64 и нажать на кнопку “Загрузка сертификата ЦС”. Полученный файл certnew.cer сохраняем.
2. Переходим по ссылке. Устанавливаем все плагины, которые от нас просят. Нажимаем на кнопку ”Создать ключ”, и выбираем для генерации алгоритм “ГОСТ Р 34.10-2012 256-бит”. Далее создаём запрос на сертификат, в графе “Применение” можно выбрать все. В графе Дополнительное применение: Аутентификация клиента и Пользователь центра регистрации КриптоПро.
3. Опять открываем сайт тестового УЦ, но на этот раз нажимаем на кнопку “Отправить готовый запрос PKCS#10 или PKCS#7 в кодировке Base64”. Вставляем в поле содержимое нашего запроса, нажимаем на клавишу “Выдать” и загружаем сертификат user.crt в формате Base64. Полученный файл сохраняем.

Через командную строку

1. Для того, чтобы получить корневой сертификат, зайдём на сайт тестового УЦ ООО “КРИПТО-ПРО”. И нажмём на кнопку для получения сертификата. Отобразится новая вкладка, в которой нужно будет выбрать метод шифрования Base64 и нажать на кнопку “Загрузка сертификата ЦС”. Полученный файл certnew.cer сохраняем.

2. Теперь генерируем ключи.

   pkcs11-tool --module /usr/lib/librtpkcs11ecp.so --keypairgen --key-type GOSTR3410-2012-256:B -l --id 45 # 45 -- код символа ASСII id ключа (E)

   Стоит заметить, что сгенерированные на токене ключи не могут быть скопированы с токена. В этом состоит одно из основных преимуществ их использования.

3. Создадим запрос на сертификат:

   openssl req -engine rtengine -new -key="pkcs11:id=E" -keyform engine -out client.req

Остался последний вопрос: Для чего всё это??? Зачем мы получали все эти сертификаты, ключи и запросы?

Дело в том, что они нужны протоколу TLS для двусторонней аутентификации. Работает это очень просто.

У нас есть сертификат сервера, и мы считаем его доверенным.

Наш клиент проверяет, что сервер, с которым мы работаем имеет аналогичный сертификат.
Сервер же хочет убедиться, что работает с пользователем, который ему известен. Для этого мы и создавали запрос на сертификат для работы через наши ключи.

Мы отправили этот запрос и сервер подписал её своей ЭЦП. Теперь мы можем каждый раз предъявлять этот сертификат, подписанный корневым УЦ, тем самым подтверждая, что мы — это мы.

Установка центра сертификации (Standalone CA Windows Server 2019)

Непосредственно перед самой установкой коротко объясню особенности Standalone CA:

• Не интегрирован с Active Directory (а он нам и не нужен);

• Публикация сертификатов происходит через запрос на WEB-сайте. Путем автоматического или ручного подтверждения администратором ЦС (ЕМНИП, ЦС предприятия было добавлена такая возможность, не проверял её работу);

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

• Не поддерживает шаблоны сертификатов (из-за этого всплывут некоторые моменты, которые раскрою в процессе развертывания).

Начинаем:

1. Измените имя компьютера до установки роли, после это будет сделать невозможно. «Далее (Next)» (рис.2):

Рисунок 2. Уведомления при установки роли.

2. Добавляем роль в «Диспетчере серверов» (Server Manager), «Далее (Next)» (рис. 3):

Рисунок 3. Интерфейс «Диспетчера устройств» (Server Manager)

2.1. «Установка ролей и компонентов (Add roles and features wizard)». Нажимаем «Далее (Next)» – «Далее (Next)»;

2.2. «Тип установки: Установка ролей и компонентов (Installation type: Role-based or features-based installation». «Далее (Next)»;

2.3. «Выбор сервера (Server selection)». В нашем случае среди предложенных будет один сервер и имя компьютера. «Далее (Next)» (рис. 4);

Рисунок 4. «Выбор сервера (Server selection)»

2.4. «Роли сервера (Server roles). Здесь необходимо отметить две роли: Служба сертификатов Active Directory (Certificate Services Active Directory), Веб-сервер IIS (Web-server IIS);

Во всплывающем окне перечня нажимаем «Добавить компонент (Add features)» – «Далее (Next)»;

2.5. «Компоненты (Features) оставляем как есть — «Далее (Next)» ;

2.6. «Служба ролей (Role Services)» ЦС, необходимо выбрать:

• «Центр сертификации (Certification Authority)»,

• «Служба регистрации в центре сертификации через Интернет (Certification Authority Enrollment)»;

Сетевой автоответчик (Online responder) добавим уже после развертывания ЦА, в противном случае могут возникнуть проблемы.

2.7. В «Служба ролей (Role Services)» веб-сервера оставляем всё предложенное автоматически — «Далее (Next)»;

2.8. «Подтверждение (Confirmation).

На этом этапе запустится процесс установки роли.

3. После установки роли центра сертификации необходимо его настроить(рис. 5). Выбираем:

3.1. «Настроить службы сертификатов Active Directory (Configure Active Directory-Certificate Services)

Рисунок 5. Уведомление о необходимости настройки центра сертификации

3.2. Указываем учетные данные. Так как мы развертываем Standalone центр сертификации, не нужно состоять в группе «Администраторов предприятия (Enterprise Administrators)» — «Далее (Next)»;

3.3. Выбираем установленные службы ролей для настройки (Select role services to configure) ЦС: «Центр сертификации (Certification Authority)», «Служба регистрации в центре сертификации через Интернет (Certification Authority Enrollment)»;

3.3.1. При выборе центра сертификации появится окно выбора ключевого носителя – КриптоПРО CSP, в качестве носителя для создания контейнера cngWorkAround используем хранилище ключей реестра Windows – Реестр. (рис. 6)

Рисунок 6. Выбор ключевого носителя – КриптоПРО CSP

3.4. Указываем вариант установки ЦС (Specify the setup type of the CA): Автономный центр сертификации (Standalone CA). «Далее (Next)»;

3.5. Указываем тип ЦС (Specify the type of CA) – Корневой ЦС (Root CA). «Далее (Next)»;

3.6. Необходимо создать закрытый ключ ЦС, чтобы он мог создавать и выдавать их клиентам. Для этого выбираем «Создать новый закрытый ключ (Create a new private key)».

В качестве поставщика службы шифрования выбираем один из трёх предложенных (не забывайте, что 2001 год уже устарел) Crypto-Pro GOST R 34.10-2012 Strong Cryptographic Service Provider с длиной 512 и открытого ключа 1024 бита. (рис.7)

И обязательно подтверждаем: «Разрешить взаимодействие с администратором, если ЦС обращается к закрытому ключу (Allow administrator interaction when the private key is accessed by the CA)»;

Рисунок 7. Выбор криптопровайдера

3.7. Укажите имя центра сертификации и суффиксы различающего имени, данные суффиксы будут отображаться в составе сертификата в графе «Издатель (Issuer)».

СN = Certificate Name, O = Organization, L = Locale, S = Street, C = Country, E = E-mail; (рис. 8)

3.8. Указываем необходимый «срок годности (validaty period)» корневого сертификата (в нашем случае было выбрано 15 лет). «Далее (Next)»;

3.9. Указываем расположение баз данных сертификатов (certificate database location). «Далее (Next)»;

3.10. В окне «Подтверждения (Confirmation) сверяем введённую информацию – «Настроить (Configure)»

3.11. Появится окно выбора носителя для создания контейнера нашего ЦС.

3.12. Далее откроется окно генерации начальной последовательности с помощью биологического ДСЧ. Для генерации случайной последовательности перемещайте указатель мыши или нажимайте различные клавиши.

3.13. После введите пароль на доступ к закрытому ключу.

3.14. Далее появится окно результатов об успешной установке компонентов (рис. 8)

Рис.8. Результаты установки

Настройка веб-сервера IIS

Теперь необходимо выполнить некоторые настройки веб-сервера: прицепить сертификат (самоподписанный или выпущенный нашим же ЦА). Кстати, он уже работает. В качестве примера выпустим самоподписанный сертификат.

1. Откроем Диспетчер служб IIS (Manager IIS) — Сертификат сервера (Server Certificates) (рис. 9);

1.1. В открывшемся окне в панели «Действия (Actions)» выберем – «Создать самоподписанный сертификат (Create Self-Signed Certificate);

1.2. Выбираем тип «Личный (Personal) и указываем «Имя сертификата (Friendly Name)»

1.3. Теперь необходимо привязать этот сертификат для доступа по https к веб-серверу.

1.3.1. Переходим «Сайты (Sites)» – Default Web Site – Bindings – добавить (Add) – выбрать https – и выбрать самоподписанный SSL-сертификат.

Рисунок 9. Диспетчер служб IIS (IIS Manager)

Также сертификат вы можете выпустить следующим образом:На этой же панели создайте запрос (Create certificate request) для выпуска сертификата через наш ЦА и дальнейшей его загрузки в IIS (Complete Certificate Request). Но это по желанию.

[NewRequest]
Subject="CN=ИмяСертификата ,O=Организация, L=Город, S=Улица, C=Страна, E=Почта"
ProviderName="Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider"
ProviderType=80
KeySpec=1
Exportable = TRUE
KeyUsage=0xf0
MachineKeySet=true
RequestType=Cert
SMIME=FALSE
ValidityPeriod=Years
ValidityPeriodUnits=2
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

В целом с веб-сервером мы закончили, в default web site вы можете увидеть, что были автоматически созданы virtual directory и applications «CertSrv». При желании можно создать отдельную виртуальную директорию под CRL’ки.

Нативные библиотеки

OpenSSL-style

Open Source библиотека OpenSSL обладает широкими криптографическими возможностями и удобным механизмом ее расширения другими криптоалгоритмами. OpenSSL является основным криптоядром для широкого спектра приложений Open Source.

После того, как в эту библиотеку компанией Криптоком были добавлены ГОСТы, появились патчи для «гостификации» многих популярных приложения, использующих OpenSSL. На базе OpenSSL некоторые вендоры разработали и сертифицировали СКЗИ, кроме того в ряд продуктов OpenSSL входит «неявным» образом.

Проблемы:

• OpenSSL и его аналоги не поддерживается приложениями Microsoft;
• Необходимость патчить СПО, которое поддерживает OpenSSL, для включения ГОСТов.

Плюсы:

• Кроссплатформенность;
• Использование в огромном количестве проектов, открытые исходники большей части проекта — выявление и устранение уязвимостей (как пример, недавнее выявление heartbleed);
• Распространяется копированием — можно делать приложения, не требующие инсталляции;
• Широкий охват приложений СПО, на базе которых можно делать защищенные сертифицированные продукты;
• Широкая интеграция в фреймворки, но при этом проблемы с ГОСТами.

PKCS#11

Библиотека PKCS#11 предоставляет универсальный кроссплатформенный программный интерфейс к USB-токенам и смарт-картам.

Функции делятся на:

• Функции доступа к устройству;
• Функции записи/чтения произвольных данных;
• Функции работы с ключами (поиск, создание, удаление, импорт, экспорт);
• Функции работы с сертификатами (поиск, импорт, экспорт);
• Функции ЭЦП;
• Функции хэширования;
• Функции шифрования;
• Функции вычисления имитовставки;
• Функции выработки ключа согласования (Диффи-Хeллман);
• Функции экспорта/импорта сессионного ключа;

Таким образом, стандарт PKCS#11 поддерживает полный набор криптопримитивов, пригодный для реализации криптографических форматов (PKCS#7/CMS/CADES, PKCS#10, X.509 и др.) и протоколов (TLS, IPSEC, openvpn и др.).

Для обеспечения быстродействия часть криптопримитивов может быть реализована программно.

В стандарте PKCS#11, начиная с версии 2.30, поддерживаются ГОСТ Р 34.10-2001, ГОСТ Р 34.11-94, ГОСТ 28147-89.

Использование библиотеки PKCS#11 обеспечивает совместимость ПО различных вендоров при работе с токенами. Через PKCS#11 интерфейс умеют работать приложения, написанные на на базе CryptoAPI, NSS, OpenSSL.

Пример совместимости приложений приведен на схеме. Таким образом, возможно использование подходящего приложения в соответствующем месте инфосистемы.

PKCS#11 бывают также без поддержки аппаратных устройств с программной реализацией криптоалгоритмов и хранением объектов в файловой системе.

Примеры – PKCS#11 интегрированный в NSS (Mozilla), проект aToken, библиотека Агава-Про.

У компании Крипто-Про есть библиотека PKCS#11, реализованная на базе MS CryptoAPI:

Существуют PKCS#11-библиотеки для мобильных платоформ. Примером подобной библиотеки служит библиотека для Рутокен ЭЦП Bluetooth, которая позволяет использовать устройство на iOS и Android.

NSS

NSS представляет собой криптографическую библиотеку от сообщества Mozilla. NSS используется такими приложениями, как браузер Mozilla Firefox, почтовым клиентом Mozilla Thunderbird.

В данный момент существуют два проекта по «гостификации» NSS:

• Компания Лисси периодически публикует на своем сайте доступные для скачивания актуальные версии Mozilla Firefox и Mozilla Thunderbird, пересобранные с поддержкой российской криптографии. Кроме того, существует ряд продуктов этой компании, построенный на базе модифицированной библиотеки NSS — высокоуровневая библиотека NSSCryptoWrapper, плагин LCSignPlugin, десктопное приложение для ЭЦП под Android SignMaker-A.
  Следует отметить, что модифицированный специалистами этой компании NSS позволяет использовать как программные PKCS#11-токены, так и аппаратные (Рутокен ЭЦП, eToken ГОСТ, JaCarta ГОСТ, MS_KEY).
• Atoken — это open source проект компании R-Альфа. В рамках проекта создан программный PKCS#11-токен с российской криптографией и выложены патчи для определенной версии NSS и компонента Security Manаger, позволяющие использовать в продуктах Mozilla россиийскую криптографию (TLS, ЭЦП, PKI). Кроме того R-Альфа предлагает реализацию программного PKCS#11-токена с поддержкой сертифицированной библиотеки Агава-С под названием Агава-Про.

Библиотеки c собственным интерфейсом

Проприетарные библиотеки предоставляют собственный API для встраивания в приложения. В данный список можно внести:

• Агава-С
• Крипто-C
• Крипто-КОМ

Установка сетевого ответчика (Online responder)

А вот мы и вернулись к установке автоответчика.

1. Добавляем роль в «Диспетчере серверов» (Server Manager) – «Далее (Next)»

1.1. Установка ролей и компонентов (Add roles and features wizard)» – «Далее (Next)»;

1.2. «Роли сервера (Server roles), раскрываем роль: Служба сертификатов Active Directory (Certificate Services Active Directory); и устанавливаем галочку на «Сетевой ответчик» (Online Responder)

1.3. Завершаем работу с мастером ролей и компонентов, путём односмысленных нажатий «Далее (Next)».

В IIS была добавлена Applications: ocsp. Только не пугайтесь, что сама по себе директория пустая. Так и должно быть.

Нам осталось настроить центр сертификации и выпустить сертификат на OCSP.

Терминология

КУЦ – код удостоверяющего центра. Является уникальным идентификатором организации в УЦ Сбербанка.

Токен – физический носитель для хранения сертификатов банка и авторизации токен-пользователя в веб-канале СББОЛ.

Инфокрипт-токен – разновидность токена банка, разработанного компанией ООО Фирма «ИнфоКрипт».

Rutoken – разновидность токена банка, разработанного компанией АО «Актив-софт».

СББОЛ – Сбербанк Бизнес Онлайн.

CMS – Cryptographic Message Syntax, в API используется в виде контейнера, в котором передается запрос на сертификат формата PKCS #10.

Bicrypt ID – идентификатор сертификата, который состоит из (КУЦ) + (номер сертификата) + (тип сертификата: s-сертификат пользователя; t-сертификат TLS) + (ФИО пользователя клиента).

ЭП/ЭЦП/ЦП – электронная цифровая подпись, которая формируется закрытым ключом сертификата ЭП.

Сертификат ЭП – сертификат электронной подписи, используется для идентификации ЭЦП клиента в полученном документе.

Пользователь партнера – учетная запись в организации, которая является владельцем сервиса.

Пользователь клиента – учетная запись в организации, которая не является владельцем сервиса.

Назначение

В API можно отправлять документы с ЭЦП или без ЭЦП:

• С ЭЦП – документ будет автоматически направляться для исполнения в АБС банка, при условии достаточности количества ЭП под документом.
• Без ЭЦП – документ будет создаваться в СББОЛ в виде черновика. Если клиент в СББОЛ не подпишет черновик документа, то документ не будет отправлен на обработку.

Использование сертификатов ЭП в API необходимо для автоматизации процесса подписания отправляемых документов.

Пример использования

На ресурс /v1/payments можно отправить документ с ЭЦП, которая будет указана в блоке digestSignatures в поле «base64Encoded» (Signature в модели JSON).

"base64Encoded"  (string): Значение электронной подписи, закодированное в Base64: MIIIhAYJKoZIhvcNAQcCoIIIdTCCCHECAQExDjAMBggqhQMHAQECAgUAMAsGCSqGSIb3DQEHAaCCBCIwggQeMIIDy6ADAgECAgp4gjWw1z9AmGQ5MAoGCCqFAwcBAQMCMIIBazEbMBkGA1UECAwSNzcg0LMu0JzQvtGB0LrQstCwMRgwFgYDVQQHDA/Qsy7QnNC+0YHQutCy0LAxGjAYBggqhQMDgQMBARIMMDA3NzA3MDgzODkzMSYwJAYDVQQJDB3Rg9C7LiDQktCw0LLQuNC70L7QstCwLCDQtC4xOTEYMBYGBSqFA2QBEg0xMDI3NzAwMTMyMTk1MQswCQYDVQQGEwJSVTErMCkGA1UECgwi0J/QkNCeINCh0LHQtdGA0LHQsNC90LogKNCi0JXQodCiKTFDMEEGA1UECww60JTQtdC/0LDRgNGC0LDQvNC10L3RgiDQsdC10LfQvtC/0LDRgdC90L7RgdGC0LggKNCi0JXQodCiKTEyMDAGA1UEAwwp0J/QkNCeINCh0LHQtdGA0LHQsNC90Log0KPQpiAo0KLQldCh0KIgUSkxITAfBgkqhkiG9w0BCQEWEmNhc2JyZkBzYmVyYmFuay5ydTAeFw0yMDA5MDQxMzI2MDBaFw0yMTEyMDQxMzI3MDNaMIHUMTcwNQYDVQQDDC7Qr9C80LrQvtCy0L7QuSDQntC60YHQsNC90LAg0J3QuNC60LjRgtC10LLQvdCwMSQwIgYDVQQKDBvQntCe0J4gItCU0JfQni3Qk9CeLTA1OC0wMSIxGzAZBgNVBAwMEtCR0YPRhdCz0LDQu9GC0LXRgDEiMCAGCSqGSIb3DQEJARYTVXNlcjA1ODAxMDJAbWFpbC5ydTELMAkGA1UEBhMCUlUxCjAIBgNVBAsMATIxGTAXBgNVBAcMENCf0L7QtNC+0LvRjNGB0LowZjAfBggqhQMHAQEBATATBgcqhQMCAiQABggqhQMHAQECAgNDAARAKiFlbfmX8rR8tFwMmBlZsCdEhVuKtT/bFbWNL/fqDxHdoF3aTIJKLpIwDzLDhM13f/YwM/mtMWA7dnmWRHBydKOB3TCB2jAoBgcqhQMDewMBBB0MG0EwMDJXQjIwc9Cv0LzQutC+0LLQvtC50J7QnTAUBgcqhQMDewMEBAkGByqFAwN7BQQwDgYDVR0PAQH/BAQDAgTwMAkGA1UdEwQCMAAwHQYDVR0OBBYEFP4LRehws6Zuxxb5DfBXtFdv2GyVMD0GA1UdHwQ2MDQwMqAwoC6GLGh0dHA6Ly93d3dsLnNiZXJiYW5rLnJ1L2NhL3Rlc3RfMjAxMng1MDkuY3JsMB8GA1UdIwQYMBaAFER+sfJUNI8vPMx8c81kE7FatnguMAoGCCqFAwcBAQMCA0EAHSMBBle64ZRowXC09XlvgZ5mwEbctEkk+8lWYQ/I7uAOuaKehAmGu1CfVzdELrzhfBjHZH7549eeGSCNTT1GKTGCBCcwggQjAgEBMIIBezCCAWsxGzAZBgNVBAgMEjc3INCzLtCc0L7RgdC60LLQsDEYMBYGA1UEBwwP0LMu0JzQvtGB0LrQstCwMRowGAYIKoUDA4EDAQESDDAwNzcwNzA4Mzg5MzEmMCQGA1UECQwd0YPQuy4g0JLQsNCy0LjQu9C+0LLQsCwg0LQuMTkxGDAWBgUqhQNkARINMTAyNzcwMDEzMjE5NTELMAkGA1UEBhMCUlUxKzApBgNVBAoMItCf0JDQniDQodCx0LXRgNCx0LDQvdC6ICjQotCV0KHQoikxQzBBBgNVBAsMOtCU0LXQv9Cw0YDRgtCw0LzQtdC90YIg0LHQtdC30L7Qv9Cw0YHQvdC+0YHRgtC4ICjQotCV0KHQoikxMjAwBgNVBAMMKdCf0JDQniDQodCx0LXRgNCx0LDQvdC6INCj0KYgKNCi0JXQodCiIFEpMSEwHwYJKoZIhvcNAQkBFhJjYXNicmZAc2JlcmJhbmsucnUCCniCNbDXP0CYZDkwDAYIKoUDBwEBAgIFAKCCAj8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwODE4MDkzNTI3WjAvBgkqhkiG9w0BCQQxIgQgp6uVTF66ax/5x186ccOnx1jZrWiTR8VCg9xEAyl61tQwggHSBgsqhkiG9w0BCRACLzGCAcEwggG9MIIBuTCCAbUwCgYIKoUDBwEBAgIEIGKL6KiLZsDSAymAPYaQY8mAwwdKEoUainKYsvPeBd87MIIBgzCCAXOkggFvMIIBazEbMBkGA1UECAwSNzcg0LMu0JzQvtGB0LrQstCwMRgwFgYDVQQHDA/Qsy7QnNC+0YHQutCy0LAxGjAYBggqhQMDgQMBARIMMDA3NzA3MDgzODkzMSYwJAYDVQQJDB3Rg9C7LiDQktCw0LLQuNC70L7QstCwLCDQtC4xOTEYMBYGBSqFA2QBEg0xMDI3NzAwMTMyMTk1MQswCQYDVQQGEwJSVTErMCkGA1UECgwi0J/QkNCeINCh0LHQtdGA0LHQsNC90LogKNCi0JXQodCiKTFDMEEGA1UECww60JTQtdC/0LDRgNGC0LDQvNC10L3RgiDQsdC10LfQvtC/0LDRgdC90L7RgdGC0LggKNCi0JXQodCiKTEyMDAGA1UEAwwp0J/QkNCeINCh0LHQtdGA0LHQsNC90Log0KPQpiAo0KLQldCh0KIgUSkxITAfBgkqhkiG9w0BCQEWEmNhc2JyZkBzYmVyYmFuay5ydQIKeII1sNc/QJhkOTAMBggqhQMHAQEBAQUABEBCRVA5m1y2f/nMz6d89nO9W6rJzkvoxhEX3Rf0SZU7CR1ENpH3bTKZbq9BNKExrARrn/RVGYDaxmNdQCM9vZHQ"certificateUuid"  (string): Уникальный идентификатор сертификата ключа проверки электронной подписи(UUID): 77507d30-c4ac-44bd-9c92-245e7d96a384

Современное состояние российской нормативной базы в области совместимости реализаций X. 509 и CMS

В период с 2012 по 2014 год ООО “КРИПТО-ПРО”, выполняя поручение технического комитета по стандартизации “Криптографическая защита информации” (ТК 26) <http://www.tc26.ru/> (рабочей группы по сопутствующим криптографическим алгоритмам, определяющим ключевые системы), разработало нормативные документы:

• Техническая спецификация. Использование алгоритмов ГОСТ Р 34.10, ГОСТ Р 34.11 в профиле сертификата и списке отзыва сертификатов (CRL) инфраструктуры открытых ключей X.509 [rus-gost-x509];

• Рекомендации по стандартизации. Использование алгоритмов ГОСТ 28147-89, ГОСТ Р 34.11 и ГОСТ Р 34.10 в криптографических сообщениях формата CMS [rus-gost-cms].

Данные документы утверждены решением весеннего заседания ТК 26.

Позже силами Рабочей группы по сопутствующим криптографическим алгоритмам и протоколам ТК 26 были разработана новая версия рекомендаций по стандартизации, позже утвержденная Росстандартом.

• Рекомендации по стандартизации Р 1323565.1.025-2019 “Информационная технология. Криптографическая защита информации. Использование алгоритмов ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012 в сертификате, списке аннулированных сертификатов (CRL) и запросе на сертификат PKCS #10 инфраструктуры открытых ключей X.509” [tc26-gost-x509].

• Рекомендации по стандартизации Р 1323565.1.025-2019 “Информационная технология. Криптографическая защита информации. Форматы сообщений, защищенных криптографическими методами” [tc26-gost-cms]

Модели Рутокен с аппаратной криптографией, которые подойдут для генерации ключей для ЕГАИС

• Рутокен ЭЦП 2.0 2100, серт. ФСБ (USB/micro/Type-C)
• Рутокен ЭЦП 2.0 3000, серт. ФСБ (USB/micro/Type-C)
• Рутокен ЭЦП 2.0 Flash, серт. ФСБ
• Смарт-карта Рутокен ЭЦП 2.0 2100, серт. ФСБ

• Рутокен ЭЦП 2.0 (2000), серт ФСБ (USB/micro)

Неизвлекаемые ключи изначально генерируются внутри устройства, подписание происходит «на борту» с использованием аппаратной криптографии токена. Какая-либо возможность извлечения или копирования закрытого ключа отсутствует.

ВАЖНО! При генерации ключевой пары по алгоритму ГОСТ Р 34.10 – 2012 следует выбирать короткий ключ 256 бит.С ключами длиной 512 бит УТМ не работает. При подключении к УТМ ключа с длиной закрытой части 512 бит в логах УТМ будет ошибка

Способ 1. С использованием «КриптоПро CSP» версии 5. 0 R2 и новее

Особенности установки «КриптоПро CSP»

Установка в Windows

• Если на компьютере с ОС Windows установлены Драйверы Рутокен, и производитсяпервичная установкаКриптоПро CSP 5.0 R2, то настройка системы будет выполнена автоматически.
• При обновлении программы с предыдущих версий КриптоПро CSP, необходимо:

1) Установить актуальную версию «Драйверов Рутокен».

2) Запустить «КриптоПро CSP» с правами Администратора.

3) Выбрать «Оборудование» — «Настроить считыватели» — «Считыватель смарт-карт PKCS#11».

Установка в Linux

Перед установкой КриптоПро CSP необходимо установить библиотеку rtpkcs11ecp.so, она доступна https://www.rutoken.ru/support/download/pkcs/.

• Если установка КриптоПро происходит скриптом install_gui.sh, то необходимо отметить пункт “Поддержка токенов и смарт-карт”.
• Если установка КриптоПро происходит скриптом install.sh, то после установки основных пакетов необходимо установить пакеты cprocsp-rdr-cryptoki и cprocsp-rdr-rutoken.

Особенности настройки «КриптоПро CSP»

В «КриптоПро CSP» версии 5.0 R2 и выше в разделе «Оборудование» — «Настроить считыватели» должен быть добавлен пункт «Все считыватели смарт-карт PKCS#11».

Если такого пункта нет, запустите «КриптоПро CSP» с правами Администратора и в этом окне добавьте считыватели, нажав на кнопку «Добавить…»

Если такой вариант считывателя отсутствует, удалите «КриптоПро CSP» и, убедившись, что вы устанавливаете версию 5.0 R2 или выше, еще раз ее установите.

1) Установите актуальную версию Драйверов Рутокен.

2) Подключите устройство из семейства Рутокен ЭЦП 2.0 к компьютеру.

3) При генерации ключей нужно использовать версию «КриптоПро CSP» версии 5.0 R2 или новее.

4) В окне выбора ключевого носителя выберите режим, который позволяет работать с внутренним криптоядром Рутокена через библиотеку PKCS#11.У вас может быть один из двух вариантов (зависит от версии КриптоПро CSP):

• Вариант 1. Выберите в списке носителей «Rutoken ECP (PKCS#11)».
• Вариант 2. Выберите в списке носителей «Rutoken ECP», а в выпадающем списке “Активный токен (pkcs11_rutoken_ecp_xxxxx).

5) После генерации ключей и записи сертификата на Рутокен, проверьте формат ключей одним из двух способов:

• Способ 1. Через «Панель управления Рутокен»: вкладка “Сертификаты”.

• Способ 2. Через «КриптоПро CSP»: вкладка «Сервис» «Протестировать…» .

Способ 2. С использованием «Генератора запросов сертификатов для Рутокен ЭЦП 2. 0 и 3

«Генератор запросов сертификатов для Рутокен ЭЦП 2.0 и 3.0» входит в состав Драйверов Рутокен.

1) Установите актуальную версию Драйверов Рутокен.

2) Подключите устройство из семейства Рутокен ЭЦП 2.0 к компьютеру.

3) Запустите «Панель управления Рутокен».

4) Перейдите на вкладку «Сертификаты».

5) Нажмите кнопку «Ввести PIN-код» и введите PIN-код Администратора.

6) Нажмите на кнопку «Выписать сертификат», откроется приложение:

Далее используйте Инструкцию по работе с Генератором запросов.

Способ 3. С использованием программы «КриптоАРМ Стандарт Плюс»

Способ 3. С использованием программы «КриптоАРМ» 5 версии

Для генерации неизвлекаемых ключей можно использовать программу КриптоАРМ 5.

Настройка центра сертификации

1. В «Диспетчере серверов (Server manager)» – выбираем «Служба сертификации Active Directory (AD CS) – правой клавишей по вашему серверу и открываем: «Центр сертификации (Certification Authority).

1.1. Вы попали в оснастку управления центром сертификации: certsrv.

1.2. Выбираем ваш центр сертификации и открываем свойства (рис. 10):

Рисунок 10. Настройка центра сертификации. Оснастка управления центром сертификации certsrv.

1.3. Следующим важным шагом выступает настройка точек распространения CDP и AIA.

Authority Information Access (AIA) — содержит ссылки на корневой сертификат центра сертификации (Certification Authority)

CRL Distribution Point — содержит ссылки на файлы CRL, которые периодически публикует сервер CA, который издал рассматриваемый сертификат. Этот файл содержит серийные номера и прочую информацию о сертификатах, которые были отозваны. (рис. 11)

Мы используем веб-сервер, который доступен как внутри сети, так и из интернета (так как сертификаты могут использоваться пользователями интернета) по одному и тому же URL.

1.4. В разделе свойства переходим в «Расширения (Extensions):

Удаляем ненужные точки распространения и оставляем локальную и внешнюю ссылку для CDP:

http://<ip_address/dns_name>/CertSrv/CertEnroll/<CaName><CRLNAmeSuffix><DeltaCRLAllowed>.crl

Ставим галочки «Включить в CRL. Включить в CDP (Include in CRL. Include in the CDP)».

AIA:

http://<ip_address/dns_name>/CertSrv/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt

Ставим галочку: «Включать в AIA- расширение выданных сертификатов (Include in the AIA extension of issued certificates)»

OCSP:

https://<ip_address/dns_name>/ocsp

Ставим галочку: «Включать в расширение протокола OCSP (Include in the online certificate status protocol (OCSP) extension)»

Рисунок 11. Настройка точек распространения AIA и CRL

В свойствах центра сертификации можно настроить автоматический выпуск сертификатов при поступившем запросе. Так вы исключаете возможность проверки указанных требуемых полей сертификатов. Для этого перейдите в «Модуль политик (Policy Module)» — «Свойства (Properties)» и выберите соответствующий пункт:

В первом случае сертификату присваивается режим ожидания, а одобрение выпуска сертификата остается за администратором;

Во втором случае из-за отсутствия шаблонов в Standalone CA сертификаты будут выпускаться автоматически. (рис. 12)

Рисунок 12. Дополнительные настройки ЦС для автоматического выпуска сертификатов

Да, центр сертификации уже функционирует и доступен по указанному dns-имени. Не забудьте открыть 80 и 443 порты для функционирования веб-сервера и online-reposnder’a, настройкой которого мы займёмся далее.

Проверить работу ЦС вы можете, перейдя в ChromiumGost или Internet Explorer или Edge (с поддержкой Internet Explorer(IE)): https://localhost/CertSrv.

При переходе по ссылке извне в IE необходимо добавить наш веб-сервер в «Надежные сайты (Trusted Sites)» в настройках в пункте «Безопасность».  Не забудьте, что должен быть установлен КриптоПро CSP, в ином случае при выпуске сертификата вам не будет доступен выбор ГОСТовского криптопровайдера (рис.13).

Рисунок 13. Веб-интерфейс центра сертификации. Формирование запроса. Правильное отображение

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

Вернёмся в оснастку certsrv к нашему центру сертификации и настроим выпуск разностных CRL. Для этого необходимо открыть «Свойства (Properties)» раздела «отозванных сертификатов (Revoked Certificates)» (рис. 14).

1. Задаём «Интервал публикации CRL (CRL Publications interval)».

1.1. Включаем публикацию разностных CRL и задаём интервал.

Кажется, что все хорошо. Но есть один момент:

«ЦС будет публиковать Delta CRL, которые содержат символ плюс «+» в имени файла (например, contoso-pica+.crl). По умолчанию IIS будет расценивать этот символ в запросе как метасимвол и не позволит клиентам скачать список отзыва. Необходимо включить двойной эскейпинг в настройках IIS, чтобы расценивать знак плюса в запросе как литерал:»

Выполните следующую команду в power shell:

Import-Module -Name WebAdministration
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter /system.webServer/security/requestFiltering -name allowdoubleescaping -Value 'true'

Рисунок 14. Настройка параметров публикации CRL.

Получение статуса запроса

Ресурс /v1/crypto/cert-requests/{externalId}/state позволяет получить информацию по статусу запроса на новый сертификат. Полученную информацию возможно использовать для контроля и анализа статуса запроса на новый сертификат.

Шаги

1. При авторизации передать в scope сервис CERTIFICATE_REQUEST.

2. Отправить GET-запрос (/v1/crypto/cert-requests/{externalId}/state) с Access Token и идентификатором запроса на сертификат externalId. Access Token передается в параметре Authorization заголовка запроса.

Модель запроса

Пример запроса

curl -X GET --header 'Accept: application/json' --header'Authorization: Bearer daf9a14c-821d-4bde-9c10-0e56e63d54a0-1'

Модель ответа

Пример ответа

Возможные статусы

Локальные прокси

Основным принципом действия локального прокси является прием незащищенного соединения от приложения, установка TLS-туннеля с удаленным сервером и передача «прикладного уровня» между приложением и удаленным сервером по этому туннелю.

Некоторые локальные прокси кроме того дополнены механизмом ЭЦП специальным образом промаркированных WEB-форм (Inter-PRO, МагПро КриптоТуннель). Существуют локальные прокси, которые предоставляют для браузера WEB API ЭЦП (систему HTTP-запросов и ответов, аналогичных программному API криптобиблиотеки).

Проблемы:

• прокси должен быть запущен;
• приложение должно работать через прокси, нужно «научить» его этому;
• могут использоваться нестандартные порты, отсюда проблемы в файрволом
• если приложение «ходит» через localhost, то, например, в адресной строке браузера прописано localhost… — нестандартно
• дополнительные ограничения на разработку web-сайта — в ряде случаев использование только относительных ссылок, чтобы не «вылететь» из туннеля
• прокси сконфигурирован на проксирование конечной группы сайтов, расширение группы — это обновление клиентского конфига
• работа через внешний прокси требует дополнительного конфигурирования локального прокси, при этом могут быть проблемы с аутентификацией пользователя на внешнем прокси

Плюсы:

• решение использует универсальную технологию, поэтому можно не бояться его устаревания;
• решение может применяться на большом числе платформ, в том числе на мобильных платформах;
• кроссбраузерность, поддержка всех WEB-серверов без модификации;
• не требует инсталляции;
• поддержка различных прикладных протоколов.

Настройка OCSP — сетевого ответчика (Online responder)

Так как у Standalone центра сертификации нет шаблонов, нам необходимо вручную сформировать запрос и выпуск сертификата для конфигурации отзыва (Array configuration) в «Управление сетевым ответчиком (Online responder management). Для это используйте следующую конфигурацию для формирования запроса

1.1. Создайте: ocsp.txt cо следующим внутренним содержанием:

[NewRequest]
Subject = "CN=Имя"
PrivateKeyArchive = FALSE
Exportable = TRUE
UserProtected = FALSE
MachineKeySet = TRUE
ProviderName = "Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider"
KeyLength = 512
UseExistingKeySet = FALSE
RequestType = PKCS10
[ApplicationPolicyStatementExtension]
Policies = OCSPSigning
Critical = false
[OCSPSigning]
OID = 1.3.6.1.5.5.7.3.9
[EnhancedKeyUsageExtension]
OID="1.3.6.1.5.5.7.3.9"
[Extensions]
1.3.6.1.5.5.7.48.1.5 = Empty

1.2. Откройте командную строку cmd. Перейдите в директорию с текстовым файлом или в будущем просто укажите полный путь при формировании запроса.

1.3. Узнаем, на какой срок сейчас выпускаются сертификаты. Для этого воспользуемся командой – certutil –getreg ca\validityperiodunits

Результат — на рис. 15.

Рисунок 15. В текущей конфигурации сертификаты выпускаются на один год

1.4. Изменим длительность выпуска сертификата:

 #Изменение выпуска сертификатов с текущего состояния на длительность в 5 лет
 certutil -setreg ca\ValidityPeriodUnits 5 
 #Перезапуск сервера
 net stop certsvc 
 net start certsvc 

1.5. Сформируем запрос и выпустим сертификат для сетевого автоответчика (рис 16.):

#Конфигурирование запроса
 certreq -new <имя>.inf <имя>.req 
 
#Формирование запроса в ЦС
 certreq -submit <имя>.req
 
#Одобрение запроса (Можно руками через оснастку управления центром сертификации)
 certutil.exe -Resubmit "Цифра запроса" 

Во время конфигурирования запроса выбираем место хранения контейнера ключа и проходим процедуру ДСЧ.

Рисунок 16. Выпуск сертификата для сетевого автоответчика

1.6. Экспортируем сертификат из центра сертификации и устанавливаем его в личные сертификаты локального компьютера.

1.6.1. После запроса сертификата открываем оснастку: Certificates (Run – MMC – Add or remove Snap-ins – Certificate),

1.6.2. Выбираем сертификат, выданный для сетевого ответчика. Нажимаем правой клавишей и открываем «Все задачи (Управление закрытыми ключами (All Tasks – Manage Private keys)».

1.6.3. В открывшемся окне Permissions необходимо добавить в «Группы и пользователи (Group and Users):   Network Service и выдать право Read для этой учётной записи. (рис.16.1)

Это нужно сделать, так как служба OCSP работает от лица Network Service.

Рисунок 16.1. Настройка сертификата для  работы сетевого ответчика

1.7. Далее переходим в настройки самого сетевого ответчика. (рис. 17)

1.8. Нам необходимо добавить «Конфигурацию отзыва (Revocation Configuration) – «Добавить»

2. Предстоит небольшой процесс настройки конфигурации отзыва.

2.1. «Далее».

2.2. Введите имя конфигурации – «Далее».

2.3. Выбираем второй пункт: «Выбрать сертификат в локальном хранилище сертификатов (Select a certificate from the local certificate store)» – «Далее».

2.4. В следующем окне нажимаем «Обзор (Browse)» и выбираем корневой сертификат нашего ЦА – «Больше вариантов (More choices)». (рис. 17) – «Далее».

2.5. В следующем окне выбираем «Выбрать сертификат подписи вручную (Manually a signing sertificate)

2.6. В последнем окне нажимаем «Поставщик (Provider)». Здесь необходимо указать источник, из которого будут браться базовые и разностные CRL. В нашем случае: http://localhost/CDP/CA-C4Y-VPN.crl (для базового) и  http://localhost/CDP/CA-C4Y-VPN+.crl (для разностного).

Рисунок 17. Управление сетевым ответчиком. (online responder management)

Рисунок 18. Прикрепляем конфигурации корневой сертификат ЦА

2.7. Осталось прицепить к нашей конфигурации выпускаемый ранее сертификат и проверить некоторые моменты.

2.7.1. Переходим в «Конфигурацию массива(array configuration)», выбираем конфигурацию и нажимаем «Назначить сертификат подписи (Assign Signing Certificate)». В появившемся окне нужно просто нажать «ОК».

2.7.2. Теперь необходимо «Обновить конфигурацию массива». Для этого выбираем «Конфигурация массива (Array configuration) – «Обновить (Refresh)»

2.7.3. После всех этих действий главное окно оснастки ocsp должно выглядеть так, как на рисунке 19.

Рисунок 19. Итоговый результат о работе сетевого ответчика

В процессе самостоятельной настройки «сетевого ответчика» может возникнуть много вопросов, особенно если нет опыта работы с Standalone центром сертификации, в котором отсутствуют шаблоны, без которых можно обойтись, но пути становятся длиннее в исполнение.  Кстати говоря, если после прикрепления сертификата вы не получили заветное Working, то проверьте следующее (рис.20, 20.1):

Рисунок 20. Переходим в редактирование свойств конфигурации отзыва

Рисунок 20.1. Проверяем что в разделе «Подписи» выбран ГОСТ алгоритм шифрования

Чтобы проверить работу центра сертификации и сетевого автоответчика, выпустите сертификат для конечного пользователя, установите его и экспортируйте в какую-нибудь директорию. А после воспользуйтесь утилитой: Certutil –url /patch/test.crt

Для подробного отчёта вы можете воспользоваться: certutil –verify –urlfetch /patch/test.crt

На этом краткое руководство по развертыванию собственного центра сертификации подошло к концу. Я постарался рассказать о большинстве трудностей и нюансов, с которыми можно столкнуться в процессе работы. Надеюсь, это руководство поможет вам.

Что ещё интересного есть в блоге Cloud4Y

→ Малоизвестный компьютер SWTPC 6800

→ Сделайте Linux похожим на Windows 95

→ Бесплатные книги, полезные для IT-специалистов и DevOps

→ WD-40: средство, которое может почти всё

→ Игры для MS-DOS с открытым исходным кодом

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем только по делу.

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

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

Шаги

1. При авторизации передать в scope сервис GET_CRYPTO_INFO.

2. Отправить GET-запрос (/v1/crypto) с Access token. Access token передается в параметре Authorization заголовка запроса.

Модель запроса

Пример запроса

curl -X GET --header 'Accept: application/json' --header'Authorization: Bearer f8ad3141-b7e8-4924-92de-3de4fd0a464e-1'

Модель ответа

Пример ответа

Выпуск нового сертификата

Ресурс /v1/crypto/cert-requests позволяет создавать запросы на выпуск нового сертификата.

Для этого необходимо:

1. Выполнить OAuth-авторизацию, в результате которой получить авторизационный токен;

2. Обратиться к ресурсу /v1/crypto и получить код удостоверяющего центра (КУЦ) – certCenterCode;

3. На основании полученного КУЦ необходимо сгенерировать уникальный тег bicryptId, состоящий из: КУЦ +порядковый номер выпущенного организацией сертификат(нумерация 00..ZZ)+символ «s». Параметр bicryptId должен содержать не менее 9-ти символов, при необходимости дополнить слева нулями порядковый номер сертификата, после чего добавляется фамилия и инициалы владельца сертификата. Подробнее про формирование Bicrypt ID см. в Дополнительной информации.

Пример

Итоговое значение bicryptId:A001P008sИвановИИ

Шаги

1. При авторизации передать в scope сервис CERTIFICATE_REQUEST.

2. Отправить POST-запрос (/v1/crypto/cert-requests) с Access Token. Access Token передается в параметре Authorization заголовка запроса.

note

В примере параметр cms заполнен для СКЗИ-Инфокрипт VPN-KEY-TLS. Для альтернативной СКЗИ необходимо заполнять следующим образом: “cms“: “—–BEGIN CERTIFICATE REQUEST—–\n … MIIIj … \n—–END CERTIFICATE REQUEST—–“.

Модель запроса

Пример запроса

"orgName": "Общество с ограниченной ответственностью \"Маша и Медведь\"","cms": "-----BEGIN CMS-----\nMIIKCAYJKoZIhvcNAQcCoIIJ+TCCCfUCAQExDDAKB