Порядок А.1–А.10 соответствует порядку пунктов Требований к функциям Заявки. Проверки (А.1, А.4 и А.8), (А.2, А.5 и А.9), (А.3, А.6 и А.10) образуют цепочки, в которых каждая последующая проверка опирается на результаты предыдущих: внутри цепочки проверки выполняются последовательно, порядок выполнения цепочек между собой произвольный. Проверка А.7 не зависит от результатов других проверок и может выполняться в любой момент.
Проверка
Требует
Наименование проверки
А.1
—
Взаимодействие с внешними информационными системами в части получения и передачи сведений о сертификатах УКЭП и о событиях жизненного цикла сертификатов УКЭП
А.2
—
Взаимодействие с внешними информационными системами в части получения и передачи сведений о сертификатах УНЭП и о событиях жизненного цикла сертификатов УНЭП
А.3
—
Взаимодействие с внешними информационными системами в части получения и передачи сведений об аккредитации удостоверяющих центров
А.4
А.1
Регистрация в распределённых реестрах сведений о сертификатах УКЭП и о событиях жизненного цикла сертификатов УКЭП
А.5
А.2
Регистрация в распределённых реестрах сведений о сертификатах УНЭП и о событиях жизненного цикла сертификатов УНЭП
А.6
А.3
Регистрация в распределённых реестрах сведений об аккредитации удостоверяющих центров
А.7
—
Маршрутизация запросов в распределённых реестрах
А.8
А.1, А.4
Формирование представления данных о сертификатах УКЭП и о событиях жизненного цикла сертификатов УКЭП
А.9
А.2, А.5
Формирование представления данных о сертификатах УНЭП и о событиях жизненного цикла сертификатов УНЭП
А.10
А.3, А.6
Формирование представления данных об аккредитации удостоверяющих центров
А.1 Проверка взаимодействия с внешними информационными системами в части получения и передачи сведений о сертификатах УКЭП и о событиях жизненного цикла сертификатов УКЭП посредством прикладного программного интерфейса (API) для использования в высоконагруженном сервисе.
Проверка обеспечивает проверку реализации пункта 1 Требований к функциям Заявки: сведения о сертификатах УКЭП и о событиях их жизненного цикла принимаются и передаются через прикладной программный интерфейс (API). Подтверждается приём корректного сертификата УКЭП в приватный канал реестра с возвратом идентификатора записи вида «дата начала действия;hashTBS», поиск сертификата по заданному фильтру, изменение статуса сертификата и логическая отмена сертификата. Созданная запись о сертификате и сформированные события истории используются далее при проверках А.4 и А.8.
Предварительные условия: развёрнут тестовый стенд с каналами сертификатов УКЭП; демонстрирующему предоставлены тестовые сертификаты УКЭП и ключ доступа к REST API (заголовок x-api-key).
№
Шаг
Ожидаемый результат
1
Выполнить запрос «Создать запись о сертификате в приватном канале» (POST /certificate/qual/create), передав сертификат УКЭП в формате PEM: curl -X POST 'http://{host}:{port}/certificate/qual/create' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"certificate": "-----BEGIN CERTIFICATE-----MIIIEDCCB72gAwIBAgILAJ98pbYAAAAACjwwCgYIKoUDBwEBAwIw…-----END CERTIFICATE-----"}'
HTTP 200; возвращён идентификатор записи вида YYYY-MM-DDTHH:MM:SSZ;hashTBS (далее — {cert}): {"cert": "2025-03-15T09:00:00Z;6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4c"}
2
Выполнить запрос «Изменить статус сертификата в приватном канале» (POST /certificate/qual/status-update) с event = 2 (прекращение действия), причиной reason = 1 (ключ подписи скомпрометирован) и updatedAt: curl -X POST 'http://{host}:{port}/certificate/qual/status-update' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"cert": "{cert}", "event": "2", "updatedAt": "2025-09-01T00:00:00Z", "reason": "1"}' и запрос «Получить сведения о сертификате» (GET /certificate/qual/{cert}/info): curl -X GET 'http://{host}:{port}/certificate/qual/{cert}/info?logicalCancelFlag=false' -H 'x-api-key: {ключ доступа}'
HTTP 200 по каждому запросу; возвращены сведения о новом событии истории, номер версии события увеличен на 1: {"version": "2", "event": "2", "updatedAt": "2025-09-01T00:00:00Z", "reason": "1", "createdAtCC": "2025-09-01T00:05:00Z"} Сведения о сертификате содержат историю из двух событий: «1» (начало действия сертификата) и «2» (прекращение действия сертификата)
3
Выполнить запрос «Получить данные сертификатов по заданному фильтру» (GET /certificate/qual/search) по ИНН владельца: curl -X GET 'http://{host}:{port}/certificate/qual/search?INN=7743123456' -H 'x-api-key: {ключ доступа}' и запрос «Логическая отмена» (POST /certificate/qual/cancel): curl -X POST 'http://{host}:{port}/certificate/qual/cancel' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"cert": "{cert}"}'
HTTP 200 по каждому запросу; сертификат найден по заданному фильтру; в ответе на запрос логической отмены logicalCancelFlag = true: [{"cert": "2025-03-15T09:00:00Z;6b86b273…5b4c"}] {"cert": "2025-03-15T09:00:00Z;6b86b273…5b4c", "logicalCancelFlag": true}
А.2 Проверка взаимодействия с внешними информационными системами в части получения и передачи сведений о сертификатах УНЭП и о событиях жизненного цикла сертификатов УНЭП посредством прикладного программного интерфейса (API) для использования в высоконагруженном сервисе.
Проверка обеспечивает проверку реализации пункта 2 Требований к функциям Заявки: сведения о сертификатах УНЭП и о событиях их жизненного цикла принимаются и передаются через прикладной программный интерфейс (API). Подтверждается приём корректных сертификатов в каналы неквалифицированных сертификатов (канал сертификатов издателей Госключ и приватный канал неквалифицированных сертификатов) с возвратом идентификатора записи вида «дата начала действия;hashTBS», изменение статуса сертификата и логическая отмена сертификата. Отличие от проверки А.1 — используемые методы каналов неквалифицированных сертификатов. Созданные записи о сертификатах и сформированные события истории используются далее при проверках А.5 и А.9.
Предварительные условия: развёрнут тестовый стенд с каналами неквалифицированных сертификатов (Госключ) и публичным каналом сертификатов УЦ; демонстрирующему предоставлены тестовые сертификаты УНЭП и ключ доступа к REST API (заголовок x-api-key).
№
Шаг
Ожидаемый результат
1
Выполнить запрос «Создать запись о сертификате в канале сертификатов издателей Госключ» (POST /certificate/goskey/create), передав сертификат издателя УНЭП в формате PEM: curl -X POST 'http://{host}:{port}/certificate/goskey/create' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"certificate": "-----BEGIN CERTIFICATE-----MIIG…-----END CERTIFICATE-----"}' и запрос «Создать запись о сертификате в приватном канале неквалифицированных сертификатов» (POST /certificate/unqual/create), передав сертификат УНЭП в формате PEM: curl -X POST 'http://{host}:{port}/certificate/unqual/create' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"certificate": "-----BEGIN CERTIFICATE-----MIIF…-----END CERTIFICATE-----"}'
HTTP 200 по каждому запросу; возвращены идентификаторы записей вида YYYY-MM-DDTHH:MM:SSZ;hashTBS (далее — {cert}, идентификатор сертификата УНЭП): {"cert": "2024-06-01T00:00:00Z;61f0a34e41dd60aedd3f4ab48b88ce547b4e0de09c888ecc026a796d1e09a82a"} {"cert": "2025-09-01T09:00:00Z;78239b086f164d8105abefad2425e20caaa4825ec52d0fd1c0d049b8076df81a"}
2
Выполнить запрос «Изменить статус сертификата в приватном канале» (POST /certificate/unqual/status-update) с event = 2 (прекращение действия) и updatedAt: curl -X POST 'http://{host}:{port}/certificate/unqual/status-update' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"cert": "{cert}", "event": "2", "updatedAt": "2025-09-05T00:00:00Z"}'
HTTP 200; возвращены сведения о новом событии истории, номер версии события увеличен на 1: {"version": "2", "event": "2", "updatedAt": "2025-09-05T00:00:00Z", "createdAtCC": "2025-09-05T00:05:00Z"}
3
Выполнить запрос «Логическая отмена» (POST /certificate/unqual/certificate-cancel), передав идентификатор сертификата, зарегистрированного на шаге 1: curl -X POST 'http://{host}:{port}/certificate/unqual/certificate-cancel' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"cert": "{cert}"}'
А.3 Проверка взаимодействия с внешними информационными системами в части получения и передачи сведений об аккредитации удостоверяющих центров посредством прикладного программного интерфейса (API) для использования в высоконагруженном сервисе.
Проверка обеспечивает проверку реализации пункта 3 Требований к функциям Заявки: сведения об аккредитации удостоверяющих центров принимаются и передаются через прикладной программный интерфейс (API). Подтверждаются регистрация удостоверяющего центра, изменение и дополнение сведений о нём, а также получение актуальных сведений о зарегистрированном удостоверяющем центре. Созданная запись удостоверяющего центра используется далее при проверках А.6 и А.10.
Предварительные условия: развёрнут тестовый стенд; запущено приложение для тестирования API; демонстрирующему предоставлен ключ доступа к REST API (заголовок x-api-key); используется тестовый УЦ с ОГРН 1027700067340, не занятым другими записями реестра.
№
Шаг
Ожидаемый результат
1
Выполнить запрос «Регистрация УЦ» (POST /ca/create), передав сведения о тестовом УЦ: curl -X POST 'http://{host}:{port}/ca/create' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"subjectOGRN": "1027700067340", "subjectINN": "7743020560", "subjectName": "АКЦИОНЕРНОЕ ОБЩЕСТВО «ИНФОТЕКС ИНТЕРНЕТ ТРАСТ»", "subjectAddress": "107078, Москва, г. Москва, ул. Мишина, д. 56, стр. 2, эт. 2, пом. IX, ком. 11"}'
HTTP 200; создана запись «Удостоверяющий центр»; возвращён идентификатор записи; служебные поля времени заполнены: {"id": "32200046-4ba6-77e3-b30a-c063f2aa6809", "subjectOGRN": "1027700067340", "subjectINN": "7743020560", "subjectName": "АКЦИОНЕРНОЕ ОБЩЕСТВО «ИНФОТЕКС ИНТЕРНЕТ ТРАСТ»", "subjectAddress": "107078, Москва, г. Москва, ул. Мишина, д. 56, стр. 2, эт. 2, пом. IX, ком. 11", "subjectSite": "", "subjectMail": "", "subjectPhone": "", "updatedAt": "", "updateCAReason": "", "linkCAReason": "", "version": 1, "createdAtCC": "2026-09-10T20:21:55Z", "updatedAtCC": "2026-09-10T20:21:55Z"}
2
Выполнить запрос «Изменение сведений об УЦ» (POST /ca/{ogrn}/update-info) с новым адресом расположения и указанием причины изменения: curl -X POST 'http://{host}:{port}/ca/1027700067340/update-info' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"subjectName": "АКЦИОНЕРНОЕ ОБЩЕСТВО «ИНФОТЕКС ИНТЕРНЕТ ТРАСТ»", "subjectAddress": "107079, Москва, г. Москва, ул. Мишина, д. 56, стр. 2, эт. 2, пом. IX, ком. 11", "updatedAt": "2025-08-12T19:03:11+03:00", "updateCAReason": "Решение о внесении изменений в устав №1 от 12.08.25", "linkCAReason": "d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35"}' и запрос «Дополнение сведений об УЦ» (POST /ca/{ogrn}/add-info) с контактными сведениями: curl -X POST 'http://{host}:{port}/ca/1027700067340/add-info' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"subjectSite": "", "subjectMail": "77@iitrust.ru", "subjectPhone": ""}'
HTTP 200 по каждому запросу; номер версии записи увеличен последовательно до 2 и 3; заполнены идентификаторы изменения и дополнения записи; изменённый адрес и контактные сведения сохранены: {"version": 2, "subjectAddress": "107079, Москва, г. Москва, ул. Мишина, д. 56, стр. 2, эт. 2, пом. IX, ком. 11", "updatedAt": "2025-08-12T19:03:11+03:00", "updateCAReason": "Решение о внесении изменений в устав №1 от 12.08.25", "linkCAReason": "d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35", "dataChangeID": "a7f4f264b06a17185184529bb6f0914901ae1bff803367c5809834060bf7b964"} {"version": 3, "subjectMail": "77@iitrust.ru", "dataAppendID": "8e08b774ef1973bf6c9f23aec4be9606fac367032ec7ac1a26fce965a3f4f1e6"}
3
Выполнить запрос «Получить УЦ по ОГРН» (GET /ca/{ogrn}/info): curl -X GET 'http://{host}:{port}/ca/1027700067340/info' -H 'x-api-key: {ключ доступа}'
HTTP 200; возвращены актуальные сведения о зарегистрированном удостоверяющем центре с учётом изменения и дополнения: {"id": "32200046-4ba6-77e3-b30a-c063f2aa6809", "subjectOGRN": "1027700067340", "subjectINN": "7743020560", "subjectName": "АКЦИОНЕРНОЕ ОБЩЕСТВО «ИНФОТЕКС ИНТЕРНЕТ ТРАСТ»", "subjectAddress": "107079, Москва, г. Москва, ул. Мишина, д. 56, стр. 2, эт. 2, пом. IX, ком. 11", "subjectSite": "", "subjectMail": "77@iitrust.ru", "subjectPhone": "", "updatedAt": "2025-08-12T19:03:11+03:00", "updateCAReason": "Решение о внесении изменений в устав №1 от 12.08.25", "linkCAReason": "d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35", "dataChangeID": "a7f4f264b06a17185184529bb6f0914901ae1bff803367c5809834060bf7b964", "dataAppendID": "8e08b774ef1973bf6c9f23aec4be9606fac367032ec7ac1a26fce965a3f4f1e6", "version": 3, "createdAtCC": "2026-09-10T20:21:55Z", "updatedAtCC": "2026-09-10T20:22:25Z"}
А.4 Проверка регистрации в распределённых реестрах сведений о сертификатах УКЭП и о событиях жизненного цикла сертификатов УКЭП для использования в высоконагруженном сервисе.
Проверка подтверждает реализацию требований пункта 4 Требований к функциям Заявки: сведения о сертификатах УКЭП и о событиях их жизненного цикла зарегистрированы в распределённом реестре, а не ограничиваются ответом метода. Получением сведений о сертификате по составному идентификатору подтверждаются структура записи о сертификате в приватном канале и сформированное событие истории «начало действия сертификата»; перенос сведений в публичный канал сервисом-ретранслятором ЕСИА с усечённым составом полей — без персональных данных владельца и без самого сертификата — подтверждается представлениями данных о сертификате (проверка А.8).
Предварительные условия: развёрнут тестовый стенд с каналами сертификатов УКЭП; демонстрирующему предоставлены тестовый сертификат УКЭП и ключ доступа к REST API (заголовок x-api-key).
№
Шаг
Ожидаемый результат
1
Выполнить запрос «Создать запись о сертификате в приватном канале» (POST /certificate/qual/create), передав сертификат УКЭП в формате PEM: curl -X POST 'http://{host}:{port}/certificate/qual/create' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"certificate": "-----BEGIN CERTIFICATE-----MIIIEDCCB72gAwIBAgILAJ98pbYAAAAACjwwCgYIKoUDBwEBAwIw…-----END CERTIFICATE-----"}'
HTTP 200; возвращён идентификатор записи вида YYYY-MM-DDTHH:MM:SSZ;hashTBS (далее — {cert}); в приватном канале создана запись о сертификате и событие истории «начало действия сертификата» (event = 1, updatedAt = дата начала действия сертификата): {"cert": "2025-03-15T09:00:00Z;dbbf1918dda363692e9ba7e991b26750bf4e54774704a61edd4d66215944111a"}
2
Выполнить запрос «Получить сведения о сертификате» (GET /certificate/qual/{cert}/info): curl -X GET 'http://{host}:{port}/certificate/qual/{cert}/info?logicalCancelFlag=false' -H 'x-api-key: {ключ доступа}'
HTTP 200; возвращены модель записи о сертификате и история изменения его статуса из приватного канала; запись содержит существенные поля модели — _id, hashTBS, issuerUUID, ownerType, сведения из сертификата (version, serialNumber, subjectPublicKeyInfo, validityNotBefore, validityNotAfter, issuer, subject, algorithmSignature, signatureValue), certificate, isChecked = true, logicalCancelFlag = false, createdAtCC, warnings; история содержит событие «1» (начало действия сертификата): {"_id": "1133e6ff-f837-8712-880f-50b4374e79e4", "hashTBS": "dbbf1918dda363692e9ba7e991b26750bf4e54774704a61edd4d66215944111a", "issuerUUID": "1133e6ff-f837-8712-880f-50b4374e79e2", "ownerType": "legal_entity", "version": "3", "serialNumber": "9f7ca5b6000000000a3c", "subjectPublicKeyInfo": [{"algorithm": "GOST R 34.10-2012 with 256 bit modulus", "publicKeyParamSet": "256 bit", "digestParamSet": "256 bit", "subjectPublicKey": "044058dc841c3cb6d5a3610cc1fce05bd728fa62666d0cdf1db88deafebaf46e49bb4eb23266c179de50c78f817e0f19813d9c066c0c3a6087a922bfd6a395150c31"}], "validityNotBefore": "2025-03-15T09:00:00Z", "validityNotAfter": "2026-03-15T09:00:00Z", "issuer": {"commonName": "АО «Инфотекс Интернет Траст»", "OGRN": "1027700067340", "INN": "7743020560"}, "subject": {"commonName": "ООО «Ромашка»", "OGRN": "1157746123456", "INN": "7743123456"}, "certificate": "-----BEGIN CERTIFICATE-----MIIIEDCCB72gAwIBAgILAJ98pbYAAAAACjww…-----END CERTIFICATE-----", "isChecked": true, "logicalCancelFlag": false, "createdAtCC": "2025-03-15T09:05:00Z", "warnings": [], "history": [{"versionStatus": "1", "event": "1", "reason": "", "updatedAt": "2025-03-15T09:00:00Z", "createdAtCC": "2025-03-15T09:05:00Z"}]}
А.5 Проверка регистрации в распределённых реестрах сведений о сертификатах УНЭП и о событиях жизненного цикла сертификатов УНЭП для использования в высоконагруженном сервисе.
Проверка подтверждает реализацию требований пункта 5 Требований к функциям Заявки: сведения о сертификатах УНЭП и о событиях их жизненного цикла доведены до распределённого реестра. Получением сведений о сертификате подтверждается структура записи о сертификате в приватном канале; получением истории изменения статуса из публичного канала подтверждается перенос сведений в публичный канал — персональные данные владельца и сам сертификат в публичный канал не переносятся. Отличие от проверки А.4 — в записи о сертификате УНЭП фиксируется определённый при внесении тип сертификата (ROOT_CA, SUB_CA, END_ENTITY), а поле issuerOGRN может быть не заполнено, если издатель не имеет ОГРН. Проверка опирается на сертификат издателя, зарегистрированный проверкой А.2, и предваряет проверку А.9.
Предварительные условия: в канале сертификатов издателей Госключ зарегистрирован сертификат издателя тестового сертификата УНЭП (результат проверки А.2); демонстрирующему предоставлены тестовый сертификат УНЭП и ключ доступа к REST API (заголовок x-api-key).
№
Шаг
Ожидаемый результат
1
Выполнить запрос «Создать запись о сертификате в приватном канале неквалифицированных сертификатов» (POST /certificate/unqual/create), передав сертификат УНЭП в формате PEM: curl -X POST 'http://{host}:{port}/certificate/unqual/create' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"certificate": "-----BEGIN CERTIFICATE-----MIIF…-----END CERTIFICATE-----"}'
HTTP 200; возвращён идентификатор записи вида YYYY-MM-DDTHH:MM:SSZ;hashTBS (далее — {cert}); в приватном канале создана запись о сертификате и событие истории «начало действия сертификата»: {"cert": "2025-04-01T09:00:00Z;58210c1506332b8dc1f03bd41d781ccd9b42cab779ecb59c9802379b1a7a59b6"}
2
Выполнить запрос «Получить сведения о сертификате» (GET /certificate/unqual/{cert}/info): curl -X GET 'http://{host}:{port}/certificate/unqual/{cert}/info?logicalCancelFlag=false' -H 'x-api-key: {ключ доступа}'
HTTP 200; возвращены модель записи о сертификате и история изменения его статуса из приватного канала; тип сертификата, определённый при внесении, зафиксирован в записи как END_ENTITY; издатель идентифицирован по значению атрибута commonName (проверка полномочности издателя по ОГРН и проверка аккредитации издателя не выполняются): {"_id": "28d00f67-c742-52bc-ac24-cf26b03ed6dc", "hashTBS": "58210c1506332b8dc1f03bd41d781ccd9b42cab779ecb59c9802379b1a7a59b6", "issuerUUID": "f7a2d504-8e3b-4f1a-9c62-5b8d1e2a7c44", "certType": "END_ENTITY", "version": "3", "serialNumber": "1b2c3d4e5f60718293a4b5c6", "subjectPublicKeyInfo": [{"algorithm": "GOST R 34.10-2012 with 256 bit modulus", "publicKeyParamSet": "256 bit", "digestParamSet": "256 bit", "subjectPublicKey": "044058dc841c3cb6d5a3610cc1fce05bd728fa62666d0cdf1db88deafebaf46e49bb4eb23266c179de50c78f817e0f19813d9c066c0c3a6087a922bfd6a395150c31"}], "validityNotBefore": "2025-04-01T09:00:00Z", "validityNotAfter": "2026-04-01T09:00:00Z", "issuer": {"commonName": "Госуслуги. Неквалифицированная электронная подпись"}, "subject": {"commonName": "Сидоров Сидор Сидорович", "surname": "Сидоров", "givenName": "Сидор", "SNILS": "11223344595", "INN": "770912345678"}, "isChecked": true, "logicalCancelFlag": false, "createdAtCC": "2025-04-01T09:05:00Z", "warnings": [], "history": [{"versionStatus": "1", "event": "1", "reason": "", "updatedAt": "2025-04-01T09:00:00Z", "createdAtCC": "2025-04-01T09:05:00Z"}]}
3
Выполнить запрос «Получить историю изменения статуса сертификата» (GET /certificate-validity/unqual/all): curl -X GET 'http://{host}:{port}/certificate-validity/unqual/all?cert={cert}' -H 'x-api-key: {ключ доступа}'
HTTP 200; возвращена история изменения статуса сертификата из публичного канала; перенесённое событие «1» (начало действия сертификата) присутствует; персональные данные владельца и сам сертификат в публичный канал не переносятся; поле issuerOGRN в записи публичного канала не заполнено, поскольку издатель не имеет ОГРН: {"history": [{"versionStatus": "1", "event": "1", "reason": "", "updatedAt": "2025-04-01T09:00:00Z", "createdAtCC": "2025-04-01T09:05:00Z"}]}
А.6 Проверка регистрации в распределённых реестрах сведений об аккредитации удостоверяющих центров для использования в высоконагруженном сервисе.
Проверка подтверждает реализацию требований пункта 6 Требований к функциям Заявки: сведения об аккредитации удостоверяющих центров доведены до распределённого реестра, а не ограничиваются ответом метода. Получением истории аккредитаций подтверждается накопление событий жизненного цикла аккредитации в записи истории. Подтверждается историчность реестра: отмена события не удаляет событие из истории, а сохраняет признак отмены и сведения об отмене. Проверка опирается на запись об удостоверяющем центре, созданную проверкой А.3, и предваряет проверку А.10.
Предварительные условия: зарегистрирован тестовый УЦ с ОГРН 1027700067340 (результат проверки А.3); демонстрирующему предоставлен ключ доступа к REST API (заголовок x-api-key).
№
Шаг
Ожидаемый результат
1
Выполнить запрос «Создать аккредитацию УЦ» (POST /ca/{ogrn}/accreditation/create), указав дату начала аккредитации 2025-01-01 и дату окончания действия аккредитации 2028-12-31: curl -X POST 'http://{host}:{port}/ca/1027700067340/accreditation/create' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"accreditationDate": "2025-01-01T12:00:00+03:00", "accreditationValidUntil": "2028-12-31T12:00:00+03:00", "accreditationReason": "Протокол Правительственной комиссии от 20.12.2024 № 12", "accreditationReasonLink": "6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b"}' и запрос «История аккредитаций УЦ» (GET /ca/{ogrn}/accreditation): curl -X GET 'http://{host}:{port}/ca/1027700067340/accreditation' -H 'x-api-key: {ключ доступа}'
HTTP 200 по каждому запросу; возвращён идентификатор аккредитации; в истории аккредитаций зафиксировано событие «предоставлена» (статус «1»): {"accreditationID": "CA_1027700067340_ACCR_1"} [{"id": "CA_1027700067340_ACCR_1", "version": 1, "subjectOGRN": "1027700067340", "updatedAt": "2025-01-01T12:00:00+03:00", "accreditationDate": "2025-01-01T12:00:00+03:00", "accreditationValidUntil": "2028-12-31T12:00:00+03:00", "accreditationReason": "Протокол Правительственной комиссии от 20.12.2024 № 12", "accreditationReasonLink": "", "status": "1", "createdAtCC": "2026-09-15T08:32:53Z", "updatedAtCC": "2026-09-15T08:32:53Z"}]
HTTP 200 по каждому запросу; статусы изменены последовательно на «3», «4», «2»; каждое изменение зафиксировано отдельным событием жизненного цикла аккредитации; номер версии записи увеличен последовательно: {"version": 2, "status": "3", "updatedAt": "2025-02-01T12:00:00+03:00"} {"version": 3, "status": "4", "updatedAt": "2025-03-01T12:00:00+03:00"} {"version": 4, "status": "2", "updatedAt": "2025-04-01T12:00:00+03:00"}
3
Выполнить запрос «Изменить аккредитацию УЦ» (POST /ca/{ogrn}/accreditation/update) со статусом «5» (аннулирование) и датой вступления изменения в силу, равной дате начала аккредитации (2025-01-01): curl -X POST 'http://{host}:{port}/ca/1027700067340/accreditation/update' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"accreditationID": "CA_1027700067340_ACCR_1", "status": "5", "updatedAt": "2025-01-01T12:00:00+03:00", "accreditationReason": "", "accreditationReasonLink": ""}' и запрос «Отменить событие аккредитации УЦ» (POST /ca/{ogrn}/accreditation/event/cancel): curl -X POST 'http://{host}:{port}/ca/1027700067340/accreditation/event/cancel' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"accreditationID": "CA_1027700067340_ACCR_1", "canceledAt": "2025-05-02T12:00:00+03:00", "accreditationReason": "отмена Протокол Правительственной комиссии от 20.12.2024 № 12", "accreditationReasonLink": "отмена 6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b"}'
HTTP 200 по каждому запросу; аккредитации установлен статус «5»; событие аннулирования помечено isCanceled = true; canceledAt и cancelHash заполнены; событие сохранено в истории (не удалено), действующим состоянием аккредитации становится предыдущее неотменённое событие — статус «2» (прекращена): {"version": 5, "status": "5", "updatedAt": "2025-01-01T12:00:00+03:00"} {"id": "CA_1027700067340_ACCR_1", "version": 5, "subjectOGRN": "1027700067340", "status": "5", "isCanceled": true, "canceledAt": "2026-09-15T08:33:24Z", "cancelHash": "325b609d01356e327dcdfb240a13685cca22d461bdf0164379b0607c72bb5a61", "createdAtCC": "2026-09-15T08:32:53Z", "updatedAtCC": "2026-09-15T08:33:15Z"}
А.7 Проверка маршрутизации запросов в распределённых реестрах для использования в высоконагруженном сервисе.
Проверка подтверждает реализацию требований пункта 7 Требований к функциям Заявки: маршрутизация запросов в распределённых реестрах выполняется по идентификатору объекта. Подтверждаются регистрация нового издателя актива в сервисном чейнкоде, ротация канала с последовательным увеличением идентификатора реестра и определение пары значений «наименование канала + наименование чейнкода», соответствующей реестру актива. Возможность доступа к данным ранее созданных каналов сохраняется.
Предварительные условия: развёрнут тестовый стенд; сервисный чейнкод развёрнут в канале ГУЦ; демонстрирующему предоставлены средства вызова методов сервисного чейнкода и учётные данные для подключения к сервисной базе данных.
№
Шаг
Ожидаемый результат
1
Вызвать метод «Регистрация реестра» (POST /registry/set), передав все поля сервисной базы данных, кроме registryID: curl -X POST 'http://{host}:{port}/registry/set' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"mspid": "IITCAMSP", "ogrn": "1027700067340", "x509Address": "Moscow", "channel": "iitccpub", "chaincode": "iitccpub_chaincode", "private_channel": "iitccpriv", "private_chaincode": "iitccpriv_chaincode", "assetType": 2}'
HTTP 200; метод возвращает идентификатор реестра со значением 0; в сервисной базе данных создана запись: {"registryID": 0} Запись содержит: registryID = 0; channelName = "iitccpub"; chaincodeName = "iitccpub_chaincode"; MSPID = "IITCAMSP"; assetType = 2; dateTimeOpened заполнен
2
Вызвать метод «Регистрация реестра» (POST /registry/set) при ротации канала, передав данные о новом реестре: curl -X POST 'http://{host}:{port}/registry/set' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"mspid": "IITCAMSP", "ogrn": "1027700067340", "x509Address": "Moscow", "channel": "iitccpub2", "chaincode": "iitccpub2_chaincode", "private_channel": "iitccpriv2", "private_chaincode": "iitccpriv2_chaincode", "assetType": 2}'
HTTP 200; метод возвращает идентификатор реестра, увеличенный на 1 относительно предыдущего значения (не более 31); создана отдельная запись о новом реестре с заполненным dateTimeOpened; в записи о ранее созданном реестре заполнен dateTimeClosed; доступ к данным ранее созданных каналов сохранён: {"registryID": 1} Запись содержит: registryID = 1; channelName = "iitccpub2"; chaincodeName = "iitccpub2_chaincode"; MSPID = "IITCAMSP"; assetType = 2; dateTimeOpened заполнен
3
Вызвать метод «Определение реестра по идентификатору объекта» (ResolveUUID, GetRegisterByUUID) сервисного чейнкода, передав UUID объекта, размещённого в действующем либо ранее созданном реестре: {"uuid": "{uuid}"}
Возвращена пара значений: channelName, chaincodeName: {"channelName": "iitccpub", "chaincodeName": "iitccpub_chaincode"} Запрос к активу выполнен в канале, соответствующем реестру, в котором размещён актив
А.8 Проверка формирования представления данных о сертификатах УКЭП и о событиях жизненного цикла сертификатов УКЭП на основании записей в распределённых реестрах для использования в высоконагруженном сервисе.
Проверка подтверждает реализацию требований пункта 8 Требований к функциям Заявки: представление данных о сертификатах УКЭП и о событиях их жизненного цикла формируется на основании записей распределённого реестра. Подтверждаются получение истории изменения статуса сертификата, определение статуса сертификата на заданный момент времени с учётом статусов сертификатов цепочки доверия и статуса аккредитации издателя и исчисление периодов действия сертификата. Проверка завершает сценарий сертификатов УКЭП и опирается на записи, сформированные проверками А.1 и А.4.
Предварительные условия: сформированы история изменения статуса тестового сертификата УКЭП и его запись в публичном канале (результаты проверок А.1 и А.4); в реестре аккредитации и сертификатов УЦ имеются сведения об аккредитации УЦ-издателя.
№
Шаг
Ожидаемый результат
1
Выполнить запрос «История статуса сертификата» (GET /certificate-validity/qual/all): curl -X GET 'http://{host}:{port}/certificate-validity/qual/all?cert={cert}' -H 'x-api-key: {ключ доступа}'
HTTP 200; возвращена история изменения статуса сертификата из публичного канала: все события (versionStatus, updatedAt, event, reason, createdAtCC): {"history": [{"versionStatus": "1", "event": "1", "reason": "", "updatedAt": "2025-03-15T09:00:00Z", "createdAtCC": "2025-03-15T09:05:00Z"}]}
2
Выполнить запрос «Статус квалифицированного сертификата на заданную дату» (GET /certificate-validity/qual/by-date), указав дату в пределах периода действия сертификата (2026-01-01): curl -X GET 'http://{host}:{port}/certificate-validity/qual/by-date?cert={cert}&time=2026-01-01T00:00:00Z' -H 'x-api-key: {ключ доступа}'
Выполнить запрос «Периоды действия квалифицированного сертификата» (GET /certificate-validity/qual/periods): curl -X GET 'http://{host}:{port}/certificate-validity/qual/periods?cert={cert}' -H 'x-api-key: {ключ доступа}'
HTTP 200; возвращён перечень периодов (from/to), вычисленный по истории изменения статуса с учётом пересечения периодов действия цепочки доверия; первый период начинается с даты начала действия сертификата: [{"from": "2025-03-15T09:00:00Z", "to": "2026-03-15T09:00:00Z"}]
А.9 Проверка формирования представления данных о сертификатах УНЭП и о событиях жизненного цикла сертификатов УНЭП на основании записей в распределённых реестрах для использования в высоконагруженном сервисе.
Проверка подтверждает реализацию требований пункта 9 Требований к функциям Заявки: представление данных о сертификатах УНЭП и о событиях их жизненного цикла формируется на основании записей распределённого реестра. Подтверждаются получение истории изменения статуса сертификата, определение статуса сертификата на заданный момент времени и исчисление периодов действия сертификата. Отличие от проверки А.8 — обращение к реестру аккредитации не выполняется, статус аккредитации издателя не определяется. Проверка завершает сценарий сертификатов УНЭП и опирается на записи, сформированные проверками А.2 и А.5.
Предварительные условия: сформированы история изменения статуса тестового сертификата УНЭП и его запись в публичном канале (результаты проверок А.2 и А.5).
№
Шаг
Ожидаемый результат
1
Выполнить запрос «История изменения статуса неквалифицированного сертификата» (GET /certificate-validity/unqual/all): curl -X GET 'http://{host}:{port}/certificate-validity/unqual/all?cert={cert}' -H 'x-api-key: {ключ доступа}'
HTTP 200; возвращена история изменения статуса сертификата из публичного канала: все события (versionStatus, updatedAt, event, reason, createdAtCC): {"history": [{"versionStatus": "1", "event": "1", "reason": "", "updatedAt": "2025-04-01T09:00:00Z", "createdAtCC": "2025-04-01T09:05:00Z"}]}
2
Выполнить запрос «Статус неквалифицированного сертификата на заданную дату» (GET /certificate-validity/unqual/by-date), указав дату в пределах периода действия сертификата (2026-01-01): curl -X GET 'http://{host}:{port}/certificate-validity/unqual/by-date?cert={cert}&time=2026-01-01T00:00:00Z' -H 'x-api-key: {ключ доступа}'
HTTP 200; возвращён статус сертификата и его цепочки на дату: по каждому сертификату цепочки — certId и localStatus (status = true, details = issued, date); для проверяемого сертификата — privateKeyStatus = true и признак пройденных форматных проверок isChecked = true; итоговый статус resultStatus = true; поле accreditationStatus в ответе отсутствует: {"target_cert": {"certId": "2025-04-01T09:00:00Z;58210c1506332b8dc1f03bd41d781ccd9b42cab779ecb59c9802379b1a7a59b6", "localStatus": {"status": true, "details": "issued", "reason": "", "date": "2025-04-01T09:00:00Z"}, "isChecked": true, "privateKeyStatus": true}, "sub_ca": {"certId": "2024-06-01T00:00:00Z;61f0a34e41dd60aedd3f4ab48b88ce547b4e0de09c888ecc026a796d1e09a82a", "localStatus": {"status": true, "details": "issued", "reason": "", "date": "2024-06-01T00:00:00Z"}}, "root_cert": {"certId": "2022-01-01T00:00:00Z;47cb8ad6484f71fac1b6c91ba7ee36a673fd8c954b9f98b1b5680280242c8b4d", "localStatus": {"status": true, "details": "issued", "reason": "", "date": "2022-01-01T00:00:00Z"}}, "resultStatus": true}
3
Выполнить запрос «Периоды действия неквалифицированного сертификата» (GET /certificate-validity/unqual/periods): curl -X GET 'http://{host}:{port}/certificate-validity/unqual/periods?cert={cert}' -H 'x-api-key: {ключ доступа}'
HTTP 200; возвращён перечень периодов (from/to), вычисленный по истории изменения статуса с учётом пересечения периодов действия цепочки доверия; первый период начинается с даты начала действия сертификата: [{"from": "2025-04-01T09:00:00Z", "to": "2026-04-01T09:00:00Z"}]
А.10 Проверка формирования представления данных об аккредитации удостоверяющих центров на основании записей в распределённых реестрах для использования в высоконагруженном сервисе.
Проверка завершает сценарий и подтверждает реализацию требований пункта 10 Требований к функциям Заявки: представление данных об аккредитации удостоверяющих центров формируется на основании записей распределённого реестра. Подтверждаются получение периодов действия аккредитации с учётом отменённых событий, определение признака действия аккредитации на заданную дату, получение полного перечня аккредитаций удостоверяющего центра и формирование перечня удостоверяющих центров по заданному статусу аккредитации. Проверка опирается на события, сформированные проверками А.3 и А.6.
Предварительные условия: сформированы события аккредитации тестового УЦ, включая отменённое (результаты проверок А.3 и А.6); демонстрирующему предоставлен ключ доступа к REST API (заголовок x-api-key).
HTTP 200; возвращён перечень периодов (from/to), вычисленный с учётом отменённых событий; первый период начинается с даты начала аккредитации (2025-01-01): {"accreditations": [{"from": "2025-01-01T12:00:00+03:00", "to": "2025-02-01T12:00:00+03:00", "status": ""}, {"from": "2025-03-01T12:00:00+03:00", "to": "2025-04-01T12:00:00+03:00", "status": ""}]}
2
Выполнить запрос «Получение сведений о статусе аккредитации УЦ на заданную дату» (GET /ca/{ogrn}/accreditation/by-date), указав дату проверки 2025-03-01 (дату возобновления аккредитации): curl -X GET 'http://{host}:{port}/ca/1027700067340/accreditation/by-date?date=2025-03-01T12%3A00%3A00%2B03%3A00' -H 'x-api-key: {ключ доступа}'
HTTP 200; на дату 2025-03-01 возвращён признак «действует»; позднейшие события не изменяют признак действия аккредитации на прошедшую дату: {"status": true}
3
Выполнить запрос «Все аккредитации УЦ» (GET /ca/{ogrn}/accreditation/all): curl -X GET 'http://{host}:{port}/ca/1027700067340/accreditation/all?sort_field=version&sort_dir=asc' -H 'x-api-key: {ключ доступа}' и запрос «Список УЦ с фильтрами» (GET /ca/list) по статусу аккредитации «2» (прекращена): curl -X GET 'http://{host}:{port}/ca/list?status=2' -H 'x-api-key: {ключ доступа}'
HTTP 200 по каждому запросу; возвращён полный перечень аккредитаций удостоверяющего центра (все версии событий, включая отменённое аннулирование); в перечне удостоверяющих центров со статусом аккредитации «2» присутствует тестовый УЦ: {"accreditations": [{"version": 1, "status": "1", "updatedAt": "2025-01-01T12:00:00+03:00"}, {"version": 2, "status": "3", "updatedAt": "2025-02-01T12:00:00+03:00"}, {"version": 3, "status": "4", "updatedAt": "2025-03-01T12:00:00+03:00"}, {"version": 4, "status": "2", "updatedAt": "2025-04-01T12:00:00+03:00"}, {"version": 5, "status": "5", "isCanceled": true, "canceledAt": "2026-09-15T08:33:24Z"}]} {"result": [{"id": "32200046-4ba6-77e3-b30a-c063f2aa6809", "subjectOGRN": "1027700067340", "subjectINN": "7743020560", "subjectName": "АКЦИОНЕРНОЕ ОБЩЕСТВО «ИНФОТЕКС ИНТЕРНЕТ ТРАСТ»", "accreditationDate": "2025-01-01T12:00:00+03:00", "accreditations": [{"from": "2025-01-01T12:00:00+03:00", "to": "2028-12-31T12:00:00+03:00", "status": "2"}], "version": 3}]}
Приложение Б
Б.1 Проверка получения сведений о сертификате при обращении к прикладному чейнкоду канала ГУЦ
Проверка подтверждает, что сведения о сертификате ГУЦ получены при непосредственном обращении к прикладному чейнкоду канала ГУЦ (mca-channel) с передачей глобального идентификатора записи. Подтверждается, что запись о сертификате в канале ГУЦ ведётся по модели без истории статусов. Проверка дополняет проверку А.8: сведения о сертификате, полученные через прикладной программный интерфейс, соответствуют записи в состоянии распределённого реестра.
Предварительные условия: развёрнут тестовый стенд; демонстрирующему предоставлен доступ к командной оболочке узла admin0.esiapeer.ru и средства вызова прикладного чейнкода (peer chaincode query); в окружении вызова доступен интерпретатор jq.
№
Шаг
Ожидаемый результат
1
Вызвать метод «Получение сведений о сертификате» (UserCertificateContract:Get) прикладного чейнкода канала ГУЦ, передав в transient-данных глобальный идентификатор записи о сертификате ГУЦ (2e4000b7-7106-72d1-962c-bddab4605cb7), с отбором целевых строк о сертификате:
Возвращены сведения о сертификате ГУЦ из приватного канала: составной идентификатор записи и глобальный идентификатор записи, совпадающий с переданным при вызове, наименование издателя, а также сведения о владельце и значение сертификата — в отличие от публичной копии усечённого состава (проверка Б.2): cert: 2026-09-28T08:14:51Z;1c91d61627e277b478fbe17aa2e2bf228b978992443cb646feeb9b1dc1f734e5 id: 2e4000b7-7106-72d1-962c-bddab4605cb7 issuer: Тестовый самоподписанный сертификат ГУЦ subject: есть certificate: есть
2
Вызвать метод «Получение сведений о сертификате» (UserCertificateContract:Get) прикладного чейнкода канала ГУЦ повторно и проверить, что запись не содержит истории статусов:
Запись о сертификате в канале ГУЦ ведётся по модели без истории статусов: history: отсутствует
Б.2 Проверка получения сведений о сертификате при обращении к прикладному чейнкоду публичного канала
Проверка подтверждает, что сведения о сертификате получены при непосредственном обращении к прикладному чейнкоду публичного канала (aca-pub-channel) по глобальному идентификатору записи. Подтверждается наличие публичной копии сведений о сертификате усечённого состава, сформированной при переносе сведений из приватного канала. Проверка дополняет проверки А.4 и А.8: сведения о переносе в публичный канал подтверждаются на уровне записи распределённого реестра.
Предварительные условия: развёрнут тестовый стенд; в публичном канале размещена публичная копия сведений о тестовом сертификате; демонстрирующему предоставлен доступ к командной оболочке узла admin0.esiapeer.ru и средства вызова прикладного чейнкода (peer chaincode query); в окружении вызова доступен интерпретатор jq.
№
Шаг
Ожидаемый результат
1
Вызвать метод «Получение сведений о публичной копии сертификата» (UserCertificateContract:GetPublic) прикладного чейнкода публичного канала, передав в transient-данных глобальный идентификатор записи о сертификате ГУЦ (2e4000b7-7106-72d1-962c-bddab4605cb7), с отбором целевых строк о сертификате:
Возвращены сведения о публичной копии сертификата: составной идентификатор записи и глобальный идентификатор записи, совпадающий с переданным при вызове: cert: 2026-09-28T08:14:51Z;1c91d61627e277b478fbe17aa2e2bf228b978992443cb646feeb9b1dc1f734e5 id: 2e4000b7-7106-72d1-962c-bddab4605cb7
2
Проверить усечённый состав публичной копии: значение сертификата и персональные данные владельца в неё не переносятся:
В публичной копии отсутствуют значение сертификата и персональные данные владельца (усечённый состав); присутствуют сведения о сроках действия сертификата и открытом ключе: поля сертификата и владельца: отсутствуют
Б.3 Проверка получения истории изменения статуса сертификата при обращении к прикладному чейнкоду публичного канала
Проверка подтверждает, что история изменения статуса сертификата получена при непосредственном обращении к прикладному чейнкоду публичного канала по составному идентификатору «дата начала действия;хэш подписываемой части». Подтверждается наличие в публичном канале сведений о событиях жизненного цикла сертификата. Проверка дополняет проверку А.8: события жизненного цикла, полученные через прикладной программный интерфейс, соответствуют записям распределённого реестра.
Предварительные условия: развёрнут тестовый стенд; в публичном канале размещены сведения о событиях жизненного цикла тестовых сертификатов; демонстрирующему предоставлен доступ к командной оболочке узла admin0.esiapeer.ru и средства вызова прикладного чейнкода (peer chaincode query); в окружении вызова доступен интерпретатор jq.
№
Шаг
Ожидаемый результат
1
Вызвать метод «Получение истории изменения статуса сертификата» (UserCertificateContract:GetStatusHistory) прикладного чейнкода публичного канала, передав в transient-данных составной идентификатор сертификата ГУЦ (2026-09-28T08:14:51Z;1c91d61627e277b478fbe17aa2e2bf228b978992443cb646feeb9b1dc1f734e5), с отбором по одному событию на строку:
Возвращён перечень событий жизненного цикла сертификата ГУЦ: по одному событию на строку (версия записи истории, дата и время вступления в силу, событие, причина). В перечне присутствует событие начала действия сертификата (код 1) с датой вступления в силу, равной дате начала действия сертификата (2026-09-28T08:14:51Z); признак отмены события isCanceled = false: 1 2026-09-28T08:14:51Z 1
2
Вызвать метод «Получение истории изменения статуса сертификата» (UserCertificateContract:GetStatusHistory) прикладного чейнкода публичного канала повторно и проверить полноту записи события жизненного цикла (версия записи истории, дата и время вступления в силу, событие, причина, признак отмены события):
Возвращена полная запись события жизненного цикла сертификата ГУЦ: версия записи истории «1», дата и время вступления в силу, событие «1» (начало действия), причина не указана, признак отмены события isCanceled = false: 1 2026-09-28T08:14:51Z 1 false
Приложение В
В.1 Проверка обработки запроса с несуществующим ОГРН
Проверка подтверждает, что запросы к методам реестра с указанием ОГРН, не зарегистрированного в реестре удостоверяющих центров, а также с ОГРН, не прошедшим форматно-логический контроль, отклоняются с возвратом кода ошибки. Проверка дополняет проверку А.3: приёму корректных сведений об удостоверяющем центре противопоставляется отказ в обработке недостоверных сведений.
Предварительные условия: развёрнут тестовый стенд; демонстрирующему предоставлен ключ доступа к REST API (заголовок x-api-key).
№
Шаг
Ожидаемый результат
1
Выполнить запрос «История аккредитаций УЦ» (GET /ca/{ogrn}/accreditation) с ОГРН, отсутствующим в реестре удостоверяющих центров: curl -X GET 'http://{host}:{port}/ca/9999999999999/accreditation' -H 'x-api-key: {ключ доступа}'
HTTP 200; запрос отклонён с возвратом кода ошибки ввиду отсутствия удостоверяющего центра в реестре; перечень событий аккредитации не возвращён
2
Выполнить запрос «Регистрация УЦ» (POST /ca/create) с ОГРН, не прошедшим форматно-логический контроль (12 цифр вместо 13): curl -X POST 'http://{host}:{port}/ca/create' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"subjectOGRN": "102770006734", "subjectINN": "7743020560", "subjectName": "АКЦИОНЕРНОЕ ОБЩЕСТВО «ИНФОТЕКС ИНТЕРНЕТ ТРАСТ»", "subjectAddress": "107078, Москва, г. Москва, ул. Мишина, д. 56, стр. 2, эт. 2, пом. IX, ком. 11"}'
HTTP 200; запрос отклонён с возвратом кода ошибки по результатам форматно-логического контроля; запись «Удостоверяющий центр» не создана
В.2 Проверка обработки идентификатора сертификата с недопустимыми символами
Проверка подтверждает, что запрос логической отмены сертификата с идентификатором, содержащим недопустимые символы (кириллицу), отклоняется с возвратом кода ошибки разбора идентификатора. Проверка дополняет проверку А.1: корректному идентификатору записи вида «дата начала действия;hashTBS» противопоставляется идентификатор с недопустимыми символами в части значения хэш-функции.
Предварительные условия: развёрнут тестовый стенд с каналами сертификатов УКЭП; демонстрирующему предоставлен ключ доступа к REST API (заголовок x-api-key).
№
Шаг
Ожидаемый результат
1
Выполнить запрос «Логическая отмена» (POST /certificate/qual/cancel), передав идентификатор сертификата с кириллицей в части значения хэш-функции: curl -X POST 'http://{host}:{port}/certificate/qual/cancel' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"cert": "2025-03-15T09:00:00Z;сертификат"}'
HTTP 200; возвращён код ошибки ERR-0731 «Ошибка разбора идентификатора cert»; логическая отмена сертификата не выполнена, запись о сертификате не изменена
В.3 Проверка обработки даты изменения статуса с неверным форматом
Проверка подтверждает, что запросы изменения статуса сертификата с датой и временем вступления изменения в силу, заданными в неверном формате, отклоняются с возвратом кода ошибки. Проверка дополняет проверку А.1: корректному значению updatedAt противопоставляется значение, не соответствующее установленному формату.
Предварительные условия: развёрнут тестовый стенд с каналами сертификатов УКЭП и УНЭП; имеются идентификаторы зарегистрированных сертификатов {cert} (результаты проверок А.1 и А.2); демонстрирующему предоставлен ключ доступа к REST API (заголовок x-api-key).
№
Шаг
Ожидаемый результат
1
Выполнить запрос «Изменить статус сертификата в приватном канале» (POST /certificate/qual/status-update), передав updatedAt в неверном формате: curl -X POST 'http://{host}:{port}/certificate/qual/status-update' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"cert": "{cert}", "event": "2", "updatedAt": "01.01.2026", "reason": "1"}'
HTTP 200; возвращён код ошибки ERR-0802 «У поля updatedAt некорректный формат»; статус сертификата не изменён, новое событие истории не сформировано
2
Выполнить запрос «Изменить статус сертификата в приватном канале» (POST /certificate/unqual/status-update), передав updatedAt в неверном формате: curl -X POST 'http://{host}:{port}/certificate/unqual/status-update' -H 'Content-Type: application/json' -H 'x-api-key: {ключ доступа}' -d '{"cert": "{cert}", "event": "2", "updatedAt": "31.02.2025"}'
HTTP 200; возвращён код ошибки ERR-0802 «У поля updatedAt некорректный формат»; статус сертификата не изменён, новое событие истории не сформировано
В.4 Проверка обработки идентификатора несуществующего сертификата
Проверка подтверждает, что запросы представлений данных о сертификате с идентификатором, отсутствующим в реестре, отклоняются с возвратом кода ошибки. Проверка дополняет проверки А.8 и А.9: корректному идентификатору зарегистрированного сертификата противопоставляется корректный по формату идентификатор несуществующего сертификата.
Предварительные условия: развёрнут тестовый стенд; демонстрирующему предоставлен ключ доступа к REST API (заголовок x-api-key).
№
Шаг
Ожидаемый результат
1
Выполнить запрос «История статуса сертификата» (GET /certificate-validity/qual/all) с идентификатором, корректным по формату, но отсутствующим в реестре: curl -X GET 'http://{host}:{port}/certificate-validity/qual/all?cert=2020-01-01T00:00:00Z;9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08' -H 'x-api-key: {ключ доступа}'
HTTP 200; возвращён код ошибки ERR-0729 «Отсутствует сертификат»; история изменения статуса не возвращена
2
Выполнить запрос «История изменения статуса неквалифицированного сертификата» (GET /certificate-validity/unqual/all) с идентификатором, корректным по формату, но отсутствующим в реестре: curl -X GET 'http://{host}:{port}/certificate-validity/unqual/all?cert=2020-01-01T00:00:00Z;9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08' -H 'x-api-key: {ключ доступа}'
HTTP 200; возвращён код ошибки ERR-0729 «Отсутствует сертификат»; история изменения статуса не возвращена
В.5 Проверка обработки запроса с неверным ключом доступа
Проверка подтверждает, что запросы к прикладному программному интерфейсу с неверным ключом доступа или без ключа доступа отклоняются, сведения не возвращаются. Проверка дополняет проверки приложений А и Б: успешному выполнению методов с действующим ключом доступа противопоставляется отказ в доступе.
Предварительные условия: развёрнут тестовый стенд; в реестре зарегистрирован тестовый УЦ с ОГРН 1027700067340 (результат проверки А.3); демонстрирующему предоставлен действующий ключ доступа к REST API.
№
Шаг
Ожидаемый результат
1
Выполнить запрос «Получить УЦ по ОГРН» (GET /ca/{ogrn}/info) с неверным ключом доступа: curl -X GET 'http://{host}:{port}/ca/1027700067340/info' -H 'x-api-key: неверный-ключ'
Запрос отклонён с возвратом кода ошибки авторизации; сведения об удостоверяющем центре не возвращены
2
Выполнить запрос «Получить УЦ по ОГРН» (GET /ca/{ogrn}/info) без заголовка x-api-key: curl -X GET 'http://{host}:{port}/ca/1027700067340/info'
Запрос отклонён с возвратом кода ошибки авторизации; сведения об удостоверяющем центре не возвращены