Ошибка при верификации цифровой подписи файла sap ноты
Если вы столкнулись с проблемой электронного подписания квалифицированной подписью, то вы так или иначе будете направлены в сторону Secure Store & Forward API (SSF-API) совместимых партнерских решений.
Для использования квалифицированной электронной подписи необходима сертифицированная криптография. В соответствии с ГОСТ Р 34.10-2001, криптография должна быть построена на сложности вычисления логарифма эллиптической кривой, и, раз такого алгоритма нет в стандартной поставке Sapcryptolib, то необходимо добавить недостающие алгоритмы с помощью SSF вызовов, т.к. использование SSF API является стандартным подходом к интеграции сторонней криптографии. Это более-менее известно.
Что однако неизвестно, так это то, что в стандартной поставке SAP NetWeaver есть компонент SAP Signature Control, который позволяет не только подписывать документы в веб-интерфейсе, но и делать это с использованием MS CryptoAPI. А это значит, что любая CryptoAPI-совместимая криптография будет обрабатывать вызовы этого компонента.
На практике это означает, что мы можем электронно подписывать документы в SAP GUI и в веб-приложениях с помощью сертифицированной российской криптографии. И делать это без покупки дополнительных SSF-продуктов!
Продемонстрируем это на простом примере:
1. Устанавливаем КриптоПро CSP 4.0.
5. Запускаем подписание, выбираем сертификат (сертификаты подгружаются из хранилища Microsoft Keystore)
6. Вводим пароль, если закрытый ключ доступен только по паролю
7. Результат подписания.
Документ подписан успешно (его верификация не прошла, т.к. наш сертификат не установлен на сервер, и, конечно, верификация в нашем примере не сработает для ГОСТ сертификата).
Также мы могли подписать и в SAP GUI, с помощью отчета SSFSDEMO
Выводы: конечно, в реальном проекте внедрения вам скорее всего понадобится функция верификации, и тогда так просто задачу уже не решить, потребуется установка SSF-совместимого продукта, его сборка под вашу ОС, установка, настройка SAP и т.д. и т.п. Тем не менее, часто бывает задача только электронного подписания документа (например, с целью отправки во-вне, без проверки “входящих” документов). С помощью этого простого примера, вы сможете подписывать документы из GUI и браузера, с помощью квалифицированных криптографических средств.
Статья посвящена выполненной мной достаточно нетривиальной задаче по интеграции электронной цифровой подписи в веб-шаблоны SAP (Business Explorer Web Application), работающие в SAP NetWeaver. Заранее извиняюсь, если в статье будут допущены ошибки в терминологии или в логике, так как с SAP работаю только 5 месяцев.
Общие сведение об ЭЦП можно получить в википедии ЭЦП
В чем заключалась задача
Есть SAP NetWeaver в роли хранилища данных Business Warehouse.
Все данные хранятся в кубах. В кубах же хранятся документы. Документом, по сути, является набор строк куба, имеющих одинаковый признак – номер документа. Работа с данными построена на базе веб-шаблонов Business Explorer Web Application. Содержимое документов отображаются в компоненте analisys item.
В некой web-форме пользователи вводят данные в таблицу, представленную analisys item. Введенные данные сохраняются в куб. После ввода данных пользователь должен поменять их статус (например, со статуса «Новый» на «Обработано»: перевод статуса происходит с помощью функции repost по значениям признака хранящего статусы данных; этот признак также находится в этом же кубе).
Так вот, необходимо подписывать введенные данные с помощью ЭЦП после ввода/сохранения данных и перед тем, как пользователь переведет эти данные со статуса «Новый» на «Обработано» (подписывать должен тот пользователь, который ввел данные).
Поиск в сети показал, что использовать ЭЦП не так то просто, как хотелось бы. В большинстве стран существуют собственные законодательные акты, регулирующие применение средств криптозащиты. Федеральный закон Российской Федерации от 10 января 2002 г. N 1-ФЗ «Об электронной цифровой подписи»
В частности устанавливаются алгоритмы, которые должны применяться при шифровании и генерации подписи. Например, алгоритм формирования и проверки электронной цифровой подписи ГОСТ Р 34.10-2001
Позиционируют себя спасителями на белом коне для SAP’овцев.Комплекс софта от них обойдется в сумму, превышающую 300 000 рублей. Программное обеспечение представляет собой API для продуктов SAP, обращаться к которому можно посредством ABAP.
Проблема в том, что данные продукты подразумевают подписание данных посредством кода ABAP. На клиенте же мы имеем только веб-страницу c JS. Исполнить код ABAP можно только на сервере, например с помощью AJAX запроса. Но возникает проблема – закрытый ключ пользователя доступен только на клиенте. Его пересылка на сервер не должна осуществляться. Решение «ЛИССИ» подразумевает работу на клиентской машине полновесного, не тонкого, клиента SAP, в котором возможно выполнение ABAP.
Поэтому я отказался от готовых решений и реализовал ЭЦП через CAPICOM CAPICOM
Реализация ЭЦП
Здесь описание того, как реализовал ЭЦП
1 Порядок применения ЭЦП
1) Администратор безопасности регистрирует сертификат в базе сертификатов. Сертификат необходимо получить от подлинного удостоверяющего центра.
3) При последующих просмотрах документа, подпись проверяется при открытии документа. Подпись извлекается из БД. Над подписью и содержимым документа проводятся криптографические операции верификации подписи.
4) Администратор безопасности может добавлять сертификаты пользователей в базу сертификатов, приостанавливать временно или постоянно их действие.
2 Реализация хранения данных
Подписи хранятся в плоской таблице «Подписи».
База сертификатов – набор из двух плоских таблиц:
Ключи – собственно сертификаты. В таблице храниться привязанный к ключу пользователь, дата начала и конца действия ключа, сам ключ, статус (блокирован или нет), описание.
Приостановки – набор возможных приостановок действия ключа. Хранит дату начало, конца и описание приостановки. Также хранит ID приостановленного ключа.
3 Архитектура системы цифровой подписи
CAPICOM – библиотека от MS, предоставляющая интерфейс к крипто провайдерам.
1 – посредством JS кода, происходят обращения к библиотеке CAPICOM
2 – Веб шаблон формирует данные для подписи (XML, описывающий DataProvider).
3 – Полученная подпись, посредством AJAX передается ABAP классу, осуществляющему сохранение подписи в плоскую таблицу.
4 – взаимодействие крипто провайдера с eToken происходит автоматически.
4 Реализация API
Класс Signer – реализует пользовательские методы –
Подписать, проверить подпись, получить последнюю подпись
Класс CryptoProvider – враппер для Capicom.
ZCL_AJAX_DIG_SIGN – реализация интерфейсных методов через Ajax.
Z_DIGITAL_SIGNER – реализация методов сохранения и поиска подписи, методов проверки действительности публичного ключа по базе ключей.
5 Дополнительно словесное описание
Рассмотрим порядок подписания\проверки документа.
Пользователь жмет на форме кнопку «Утвердить(сохранить) документ». JS собирает с с html кода шаблона контент документа, предварительно выгруженный туда. Обращается к CAPICOM, который просит у человека выбрать нужный сертификат. При выборе сертификата сделанного под криптоПро специально для работы в системе – CAPICOM обратиться к провайдеру КриптоПРО, тот же попросит токен с закрытым ключом. Когда токен вставят – контент документа будет подписан. Подпись по AJAX кидается в BSP приложение, оно передает подпись в интерфейсный класс Z_DIGITAL_SIGNER. Класс проверит сертификат из подписи, факт того, что именно такой сертификат привязан к данному залогинившемуся пользователю. В случае успеха проверки – запишет подпись в базу подписей. На форме произойдут изменения – появиться отметка о успешной подписи.
При открытии документа другим пользователем –появиться статус подписания. Это произойдет следующим образом. JS по AJAX запросит подписи для документа, получит подпись (априорно – она сделана нужным человеком и подпись сделана сертификатом из базы разрешенных сертификатов). Затем js дергает CAPICOM — метод «верификация подписи» с параметрами «подпись» и «контент документа». Если с документом и подписью все в порядке – метод вернет true, следовательно, документ подписан и корректен.
Также есть GUI для администратора безопасности – ведение базы активных сертификатов.
Подключение ЭЦП к веб-шаблону
1) подключить в XHTML веб шаблона ActiveX компонент CAPICOM, например
2) Создать новый провайдер данных с тем же запросом, что и основной. То есть, сделать копию провайдера. Таким образом получим выгруженный документ в HTML, который будем подписывать. Нельзя подписывать провайдер, который выводит документ в таблицу пользователя, потому что, при сортировки или фильтрации таблицы — данные в провайдеры будут меняться, а нам нужен документ в начальном виде.
3) Разместить на форме компонент «провайдер данных-информация».
Назовем его DATA_PROVIDER_TO_SIGN.
Синим- компонент «провайдер данных-информация», красным — он же в палитре компонентов, желтым — провайдер данных, поставляющий контент документа
4) Укажем в настройках DATA_PROVIDER_TO_SIGN:
Провайдер данных: Укажем созданную в шаге 2 копию провайдера.
Статус навигации — вывод: Off
Данные отчета: вывод: On
5) Размещаем на форме код
Здесь уже все зависит от вашей фантазии. Не буду постить ВЕСЬ свой код, включающий AJAX, ABAP, JavaScript, оставлю только простенький врапер для CAPICOM, который я сделал на основе примеров с сайта Microsoft.
Все чаще получаю запросы от заказчиков об использовании электронной подписи в их решениях. Зачастую сама идея внедрения электронной подписи уже вызывает множество вопросов, как технического характера, так и общего – всвязи со столкновением с весьма специфической областью информационной безопасности, имеющей множество нюансов и отсылок к законодательству. Этой статьей я хочу показать, что применение ЭП – это просто.
Немного истории
В 1977 г. Ronald Rivest, Adi Shamir, и Len Adleman публикуют свою статью “Метод получения электронной подписи и криптосистемы с открытым ключом” (здесь и далее мой перевод):
Вероятно, эра электронной почты уже близко. Мы должны быть уверены, что можем сохранить два важных свойства текущей “бумажной почты”: письма должны остаться персональными и – могут быть подписаны лично. В нашей статье мы продемонстрируем как внедрить эти свойства в систему электронной почты. Сердцем нашего предложения будет новый метод шифрования. Он применяет элегантную концепцию “криптосистем с открытым ключей” предложенной Diffie и Hellman.
Принцип, предложенный Diffie и Hellman можно проиллюстрировать на примере “красок”. Каждая из сторон обладает своей собственной “секретной” краской, но обменивается с партнером только смесью красок (Alice – оранжевым и Bob – голубым в качестве “приветствия”; второй раз – коричневым в качестве ключа шифрования). Предполагается, что найти “секретную” краску в смеси не представляется возможным.
Всемирно известный теперь алгоритм RSA в области электронной подписи (по первым буквам фамилий Ronald Rivest, Adi Shamir, and Len Adleman) полностью реализует принцип, предложенный Diffie и Hellman.
Фактически, в двух упомянутых статьях в 1976–1977 гг была заложена основа для 95% используемой на сегодня криптографии. Клиент-серверное шифрование, межсерверное шифрование, электронная подпись и пр., – все это результат использования предложенных 39 лет назад принципов.
Электронная подпись в России
Иронично, но не смотря на то, что прошло уже почти 40 лет с момента публикации алгоритмов RSA, мы до сих пор вынуждены хранить абсолютное большинство документов в бумажном виде.
Тем не менее, мир не стоит на месте, и с каждым годом законодательство разрешает все больше и больше документов переводить в электронную форму, используя электронную подпись для придания документам юридической значимости. Нет сомнений, что в перспективе на 20 лет вперед, все законодательные барьеры будут устранены и необходимость хранить бумажные документы отпадет вовсе. Опыт Эстонии, в которой функции электронной подписи используются даже в таких тонких сферах как при проведении голосования (в т.ч. в парламент), хороший тому пример.
- Электронные торги
- Внутренний юридически значимый электронный документооборот
- Внешний юридически значимый электронный документооборот
- Электронная отчетность в государственные органы
- Информационный обмен с органами государственной власти
Если на вашем предприятии уже есть электронный документооборот, то с помощью электронной подписи вы можете придать ему юридическую значимость. В случае коммуникации с заказчиками, подрядчиками и государственными органами, использование электронной подписи ускоряет взаимодействие, в конечном итоге сокращая издержки.
Электроная подпись в SAP
Один из наших клиентов в области нефти и газа экономит 4 млн рублей ежегодно только лишь на одной печати документов, заменив распечатку инвентаризационных карточек хранением документов в подписанном ЭП виде. В качестве средств криптографической защиты информации (СКЗИ) специалисты SAP рекомендовали использовать библиотеку sapcryptolib. Наряду с commoncryptolib она может устанавливаться в стандартный пакет поставки большинства решений SAP. Необходимо отметить, что раз эти библиотеки имеют реализацию криптографических средств, то они подпадают под действие регуляторов. Уточняйте, может ли ваша организация их импортировать.
К модулям FI (Финансы), SD (Сбыт), HR (Персонал), и другим, уже подключен стандартный криптопровайдер SAP:
Таким образом, функция ЭП уже реализована на уровне платформы SAP NetWeaver, это означает, что функции подписи и верификации документов уже доступны для бизнес-процессов предприятия. Остается их только подключить.
Говоря о квалифицированной ЭП, надо понимать, что требования к такому типу ЭП отличаются от страны к стране. Так, например, немецкий Акт об Электронной подписи (“Signaturgesetz”) от 1997 года требует, чтобы используемые в ЭП сертификаты выдавались квалифицированным удостоверяющим центром, для подписания использовались только отдельные устройства – смарткарты или токены, а сами подписываемые электронные документы должны записываться только на неизменяемые носители (например, на оптические диски).
Поэтому в вопросах реализации квалифицированной ЭП, SAP полагается на помощь партнеров-разработчиков СКЗИ.
Принципиальным требованием ФСБ при сертификации ПО для квалифицированной ЭП является использование ГОСТ 28147-89, ГОСТ Р 34.11-94, ГОСТ Р 34.10-2001 в реализации криптографических алгоритмов (на июнь 2015 года требования на применение ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012 до конца не регламентированы)
Технически, применение криптоалгоритмов ГОСТ в SAP достигается простым переключением «обертки» (wrapper) СКЗИ. “Обертка” подменяет собой использование стандартной библиотеки sapcryptolib обращением к любому стороннему СКЗИ, построенному на ГОСТ. Например, СКЗИ «ЛИССИ-CSP», “КриптоПро CSP”, “Валидата CSP” – если мы говорим об интерфейсе MS CSP; ПБЗИ «СКЗИ LirSSL», если используется интерфейс OpenSSL; ruTokenЭЦП/eTokenGOST если мы говорим об токенах/смарт-картах с интерфейсом PKCS11. В частности, решение ООО «ЛИССИ-Софт» под названием «FoxSSF» позволяет использовать СКЗИ с поддержкой всех трех вышеперечисленных интерфейсов. В следующей нашей статье мы более подробно поговорим о решениях, позволяющих подписывать документы SAP квалифицированной электронной подписью.
- по истечении срока действия сертификата или алгоритма не нужно “переподписывать” документ
- исключается техническая возможность сдвинуть время подписания назад и использовать скопрометированный сертификат/алгоритм – по причине наличия подписи службы штампов времени (Time Stamp Protocol – TSP) на архивированных документах.
Статья посвящена выполненной мной достаточно нетривиальной задаче по интеграции электронной цифровой подписи в веб-шаблоны SAP (Business Explorer Web Application), работающие в SAP NetWeaver.
Заранее извиняюсь, если в статье будут допущены ошибки в терминологии или в логике.
Общие сведение об ЭЦП можно получить в википедии ЭЦП
В чем заключалась задача
Есть SAP NetWeaver в роли хранилища данных Business Warehouse.
Все данные хранятся в кубах. В кубах же хранятся документы. Документом, по сути, является набор строк куба, имеющих одинаковый признак – номер документа. Работа с данными построена на базе веб-шаблонов Business Explorer Web Application. Содержимое документов отображаются в компоненте analisys item.
В некой web-форме пользователи вводят данные в таблицу, представленную analisys item. Введенные данные сохраняются в куб. После ввода данных пользователь должен поменять их статус (например, со статуса «Новый» на «Обработано»: перевод статуса происходит с помощью функции repost по значениям признака хранящего статусы данных; этот признак также находится в этом же кубе).
Так вот, необходимо подписывать введенные данные с помощью ЭЦП после ввода/сохранения данных и перед тем, как пользователь переведет эти данные со статуса «Новый» на «Обработано» (подписывать должен тот пользователь, который ввел данные).
Поиск в сети показал, что использовать ЭЦП не так то просто, как хотелось бы. В большинстве стран существуют собственные законодательные акты, регулирующие применение средств криптозащиты. Федеральный закон Российской Федерации от 10 января 2002 г. N 1-ФЗ «Об электронной цифровой подписи»
В частности устанавливаются алгоритмы, которые должны применяться при шифровании и генерации подписи. Например, алгоритм формирования и проверки электронной цифровой подписи ГОСТ Р 34.10-2001
Позиционируют себя спасителями на белом коне для SAP’овцев.Комплекс софта от них обойдется в сумму, превышающую 300 000 рублей. Программное обеспечение представляет собой API для продуктов SAP, обращаться к которому можно посредством ABAP.
Проблема в том, что данные продукты подразумевают подписание данных посредством кода ABAP. На клиенте же мы имеем только веб-страницу c JS. Исполнить код ABAP можно только на сервере, например с помощью AJAX запроса. Но возникает проблема – закрытый ключ пользователя доступен только на клиенте. Его пересылка на сервер не должна осуществляться. Решение «ЛИССИ» подразумевает работу на клиентской машине полновесного, не тонкого, клиента SAP, в котором возможно выполнение ABAP.
Поэтому я отказался от готовых решений и реализовал ЭЦП через CAPICOM CAPICOM
Реализация ЭЦП
Здесь описание того, как реализовал ЭЦП
1 Порядок применения ЭЦП
1) Администратор безопасности регистрирует сертификат в базе сертификатов. Сертификат необходимо получить от подлинного удостоверяющего центра.
3) При последующих просмотрах документа, подпись проверяется при открытии документа. Подпись извлекается из БД. Над подписью и содержимым документа проводятся криптографические операции верификации подписи.
4) Администратор безопасности может добавлять сертификаты пользователей в базу сертификатов, приостанавливать временно или постоянно их действие.
2 Реализация хранения данных
Подписи хранятся в плоской таблице «Подписи».
База сертификатов – набор из двух плоских таблиц:
Ключи – собственно сертификаты. В таблице храниться привязанный к ключу пользователь, дата начала и конца действия ключа, сам ключ, статус (блокирован или нет), описание.
Приостановки – набор возможных приостановок действия ключа. Хранит дату начало, конца и описание приостановки. Также хранит ID приостановленного ключа.
3 Архитектура системы цифровой подписи
CAPICOM – библиотека от MS, предоставляющая интерфейс к крипто провайдерам.
1 – посредством JS кода, происходят обращения к библиотеке CAPICOM
2 – Веб шаблон формирует данные для подписи (XML, описывающий DataProvider).
3 – Полученная подпись, посредством AJAX передается ABAP классу, осуществляющему сохранение подписи в плоскую таблицу.
4 – взаимодействие крипто провайдера с eToken происходит автоматически.
4 Реализация API
Класс Signer – реализует пользовательские методы –
Подписать, проверить подпись, получить последнюю подпись
Класс CryptoProvider – враппер для Capicom.
ZCL_AJAX_DIG_SIGN – реализация интерфейсных методов через Ajax.
Z_DIGITAL_SIGNER – реализация методов сохранения и поиска подписи, методов проверки действительности публичного ключа по базе ключей.
5 Дополнительно словесное описание
Рассмотрим порядок подписания\проверки документа.
Пользователь жмет на форме кнопку «Утвердить(сохранить) документ». JS собирает с с html кода шаблона контент документа, предварительно выгруженный туда. Обращается к CAPICOM, который просит у человека выбрать нужный сертификат. При выборе сертификата сделанного под криптоПро специально для работы в системе – CAPICOM обратиться к провайдеру КриптоПРО, тот же попросит токен с закрытым ключом. Когда токен вставят – контент документа будет подписан. Подпись по AJAX кидается в BSP приложение, оно передает подпись в интерфейсный класс Z_DIGITAL_SIGNER. Класс проверит сертификат из подписи, факт того, что именно такой сертификат привязан к данному залогинившемуся пользователю. В случае успеха проверки – запишет подпись в базу подписей. На форме произойдут изменения – появиться отметка о успешной подписи.
При открытии документа другим пользователем –появиться статус подписания. Это произойдет следующим образом. JS по AJAX запросит подписи для документа, получит подпись (априорно – она сделана нужным человеком и подпись сделана сертификатом из базы разрешенных сертификатов). Затем js дергает CAPICOM — метод «верификация подписи» с параметрами «подпись» и «контент документа». Если с документом и подписью все в порядке – метод вернет true, следовательно, документ подписан и корректен.
Также есть GUI для администратора безопасности – ведение базы активных сертификатов.
Подключение ЭЦП к веб-шаблону
1) подключить в XHTML веб шаблона ActiveX компонент CAPICOM, например
2) Создать новый провайдер данных с тем же запросом, что и основной. То есть, сделать копию провайдера. Таким образом получим выгруженный документ в HTML, который будем подписывать. Нельзя подписывать провайдер, который выводит документ в таблицу пользователя, потому что, при сортировки или фильтрации таблицы — данные в провайдеры будут меняться, а нам нужен документ в начальном виде.
3) Разместить на форме компонент «провайдер данных-информация».
Назовем его DATA_PROVIDER_TO_SIGN.
Синим- компонент «провайдер данных-информация», красным — он же в палитре компонентов, желтым — провайдер данных, поставляющий контент документа
4) Укажем в настройках DATA_PROVIDER_TO_SIGN:
Провайдер данных: Укажем созданную в шаге 2 копию провайдера.
Статус навигации — вывод: Off
Данные отчета: вывод: On
5) Размещаем на форме код
Здесь уже все зависит от вашей фантазии. Не буду постить ВЕСЬ свой код, включающий AJAX, ABAP, JavaScript, оставлю только простенький врапер для CAPICOM, который я сделал на основе примеров с сайта Microsoft.
Типовые ошибки при формировании подписи в веб-интерфейсе сервиса подписи.
1.1. Размер переданного файла превышает максимально допустимый размер
1.2. Неперехваченное исключение: Код состояния ответа не указывает на успешное выполнение: 413 (Request entity too large)
Возможные причины возникновения ошибки:
На подпись был передан документ, чей размер превышает заданный в настройках сервисов DSS.
Рекомендуемое решение:
Изменить значения для максимальных размеров документов сервисов DSS, в соответствие с руководством.
2. Неперехваченное исключение: Message: invalid_certificate MessageDetail: Сертификат не найден или недействителен
Диагностика:
Ошибка в «Журналы приложений и служб -> CryptoPro-> DSS-> SignServer-> Admins».
Пример:
Instance Unique Identifier: 1/signserver Source: SignDocumentRequestValidator Message: SignDocumentRequestValidator. Ошибка: invalid_certificate;
Описание: Сертификат не найден или недействителен.;
Возможные причины возникновения ошибки:
- Ошибка при проверке сертификата подписанта на сервере DSS;
- Сертификат подписанта был отозван/приостановлен.
Рекомендуемое решение:
- Обеспечить проверку сертификата подписанта на сервере DSS (путем установки цепочки сертификатов издателей в хранилище локального компьютера сервера DSS);
- Обеспечить проверку сертификата подписанта на сервере DSS на отзыв (путем установки CRL в хранилище «Промежуточные центры сертификации» локального компьютера сервера DSS или обеспечив доступность CRL по ссылкам, указанным в расширении "Точки распространения списков отзыва" сертификата подписанта и цепочки сертификатов издателей);
- Убедиться, что сертификат подписанта не был отозван/приостановлен.
3. При формировании подписи формата CAdES T/XLT1 возвращается ошибка "Произошла ошибка при получении штампа времени. Ошибка: [При попытке отправки запроса возникла ошибка HTTP]. Код: [0xc2100100]"
Возможные причины возникновения ошибки:
С сервера DSS нет сетевой доступности до службы штампов времени (TSP), выбранной при формировании подписи.
Рекомендуемое решение:
Обеспечить сетевую доступность до службы штампов времени с сервера DSS. Затем проверить работоспособность службы, в соответствие с п. 7.2 "ЖТЯИ.00094-01 91 02 Службы УЦ 2.0. КриптоПро TSP Server. Руководство администратора".
4. При формировании подписи формата CAdES XLT1 возвращается ошибка "Произошла ошибка при получении OCSP-ответа. Ошибка: [При попытке отправки запроса возникла ошибка HTTP]. Код: [0xc2110100]"
Возможные причины возникновения ошибки:
С сервера DSS нет сетевой доступности до службы проверки статусов сертификатов (OCSP), адрес которой указан в расширении "Доступ к информации о центрах сертификации" сертификата подписанта.
Рекомендуемое решение:
Обеспечить сетевую доступность до службы проверки статусов сертификатов. Затем проверить работоспособность службы, в соответствие с п. 7.3 "ЖТЯИ.00094-01 91 01 Службы УЦ 2.0. КриптоПро OCSP Server. Руководство администратора".
5. При формировании подписи формата CAdES T/XLT1 возвращается ошибка "Произошла ошибка при формировании CAdES подписи. Ошибка: [Группа или ресурс не находятся в нужном состоянии для выполнения требуемой операции]. Код: [0x8007139f]"
Возможные причины возникновения ошибки:
Остановлена служба штампов времени (TSP)/проверки статусов сертификатов (OCSP).
Рекомендуемое решение:
Запустить службы на стороне сервера "КриптоПро Службы УЦ". Затем проверить работоспособность службы штампов времени, в соответствие с п. 7.2 "ЖТЯИ.00094-01 91 02 Службы УЦ 2.0. КриптоПро TSP Server. Руководство администратора" и работоспособность службы проверки статусов сертификатов, в соответствие с п. 7.3 "ЖТЯИ.00094-01 91 01 Службы УЦ 2.0. КриптоПро OCSP Server. Руководство администратора".
6. При загрузке документа для подписи возвращается ошибка "Message: Authorization has been denied for this request"
Диагностика:
Ошибки в «Журналы приложений и служб -> CryptoPro-> DSS-> DocumentStore-> Admins».
Б) Instance Unique Identifier: 1/documentstore] Source: Microsoft.Owin.Security.OAuth.OAuthBearerAuthenticationMiddleware Message: Authentication failed
System.IdentityModel.Tokens.SecurityTokenSignatureKeyNotFoundException: IDX10505: Unable to validate signature. The 'Delegate' specified on TokenValidationParameters, returned a null SecurityKey.
Возможные причины возникновения ошибки:
- На сервисе обработки документов не настроены отношения доверия с центром идентификации;
- Истек срок действия сервисного сертификата сервиса обработки документов.
Рекомендуемое решение:
- Запросить отпечаток сервисного сертификата ЦИ: $idp_cert = (Get-DssStsProperties).ServiceCertificate
- Указать отпечаток сервисного сертификата ЦИ на сервисе обработки документов: Add-DssDocumentStoreClaimsProviderTrust -IssuerName realsts -Thumbprint $idp_cert
Примечание: если при выполнении второго командлета в Powershell возникла ошибка "Доверенный издатель с именем realsts уже добавлен в коллекцию" - необходимо выполнить командлет: Set-DssDocumentStoreClaimsProviderTrust -IssuerName realsts -NewThumbprint $idp_cert
- Проверить срок действия сервисного сертификата сервиса обработки документов. Если срок действия истек - необходимо перевыпустить его и скорректировать настройки в соответствие с руководством;
- Перезагрузить пулы приложений центра идентификации и сервиса обработки документов, выполнив командлеты: Restart-DssStsInstance и Restart-DssDocumentStoreInstance.
7. При загрузке документа для подписи возвращается ошибка "Неперехваченное исключение: Message: An error has occured"
Диагностика:
Ошибка в «Журналы приложений и служб -> CryptoPro-> DSS-> SignServer-> Admins».
Возможные причины возникновения ошибки:
- На сервисе обработки документов не настроены отношения доверия с сервисом подписи;
- Истек срок действия сервисного сертификата сервиса обработки документов.
Рекомендуемое решение:
- Запросить отпечаток сервисного сертификата сервиса подписи: $ss_cert = (Get-DssProperties).ServiceCertificate
- Указать отпечаток сервисного сертификата сервиса подписи в настройках сервиса обработки документов: Add-DssDocumentStoreClaimsProviderTrust -IssuerName signserver -Thumbprint $ss_cert
Примечание: если при выполнении второго командлета в Powershell возникла ошибка "Доверенный издатель с именем signserver уже добавлен в коллекцию" - необходимо выполнить командлет: Set-DssDocumentStoreClaimsProviderTrust -IssuerName signserver -NewThumbprint $ss_cert
- Проверить срок действия сервисного сертификата сервиса обработки документов. Если срок действия истек - необходимо перевыпустить его и скорректировать настройки в соответствие с руководством;
- Перезагрузить пулы приложений сервиса подписи и сервиса обработки документов, выполнив командлеты: Restart-DssSignServerInstance и Restart-DssDocumentStoreInstance.
Читайте также: