Подписант уже не работает

Подписант уже не работает

Типовые ошибки при формировании подписи в веб-интерфейсе сервиса подписи.

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».

А) Неавторизованный доступ по пути [https://testdss/documentstore/api/documents]: Недостаточно прав у пользователя []

Б) 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».

Пример:
Instance Unique Identifier: 1/signserver Source: Signature Message: Message: Authorization has been denied for this request.
CryptoPro.DSS.Common.Clients.Rest.DssClientException: Message: Authorization has been denied for this request.

Возможные причины возникновения ошибки:
— На сервисе обработки документов не настроены отношения доверия с сервисом подписи;
— Истек срок действия сервисного сертификата сервиса обработки документов.

Рекомендуемое решение:
— Запросить отпечаток сервисного сертификата сервиса подписи: $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.

Источник

Этот сертификат содержит недействительную цифровую подпись: как исправить ошибку

Чтобы воспользоваться квалифицированной электронно-цифровой подписью (далее — КЭЦП, КЭП, ЭЦП), криптопровайдер должен признать сертификат пользователя доверенным, то есть надежным. Это возможно, если правильно выстроена цепочка доверия сертификации, которая состоит из трех звеньев:

• сертификат ключа проверки электронной подписи (далее — СЭП, СКПЭП, СКЭП);
• промежуточный сертификат (ПС) удостоверяющего центра;
• корневой сертификат (КС) от головного центра, то есть от Минкомсвязи.

Искажение хотя бы одного файла приводит к недействительности сертификата, и он не может быть использован для визирования документации. Среди других причин сбоя выделяют неправильную работу криптопровайдера (средства криптозащиты или СКЗИ), несовместимость с браузером и др.

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

Этот сертификат содержит недействительную цифровую подпись : на примере « Тензор»

О содержании недействительной цифровой подписи в сертификате пользователь узнает при попытке подписать документы с помощью КЭЦП. В этом случае на экране появляется сообщение: «При проверке отношений доверия произошла системная ошибка» или «Не удается построить цепочку доверия для доверенного корневого центра». Чтобы увидеть состояние ключа, необходимо:

1. Открыть меню «Пуск».
2. Перейти во вкладку «Все программы» → «КриптоПро».
3. Кликнуть на кнопку «Сертификаты».
4. Выбрать хранилище: «Личное», «Доверенные корневые центры» или «Промежуточные доверенные центры».
5. Нажать на выбранный сертификат.
6. Перейти во вкладку «Путь сертификации».

В поле «Состояние» отображается статус недействительного сертификата , на примере с УЦ «Тензор» это выглядит так:

При корректно настроенном пути сертификации состояние было бы таким:

В разделе «Общие» отображается причина, например, «Этот сертификат не удалось проверить, проследив его до доверенного центра».

Системное оповещение о сбое может возникать по ряду причин:

• нарушена цепочка доверия (неверный путь сертификации), поврежден один из сертификатов или все три (шифрованное соединение между браузером клиента и сервером будет недоверенным или вовсе не будет работать);
• неправильно установлен криптопровайдер КриптоПро;
• неактивны алгоритмы шифрования СКЗИ;
• заблокирован доступ к файлам из реестра;
• старые версии браузеров;
• на ПК установлены неактуальные дата и время и т. д.

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

КЭП (ЭЦП)

Рутокен ЭЦП

Этот сертификат содержит недействительную цифровую подпись : цепочка доверия от Минкомсвязи до пользователя

Прежде чем разбираться в причинах ошибки, следует понять алгоритм построения цепочки доверия сертификатов (ЦДС) — она обязательна для корректной работы ЭЦП на любых информационных ресурсах.

Как строится путь доверия

Первое звено в иерархической цепочке — корневой сертификат ключа проверки ЭЦП ПАК «Минкомсвязь России». Именно этот госорган, согласно ст. 16 ФЗ № 63 «Об электронной подписи», осуществляет аккредитацию удостоверяющих центров, то есть дает им официальное право заниматься выпуском ЭЦП. Полный перечень таких организаций можно уточнить на официальном портале Минкомсвязи .

КС предоставляется клиенту поставщиком при выдаче КЭП, также его можно скачать на сайте roskazna.ru или самого УЦ. В цепочке доверия он играет первостепенную роль — подтверждает, что КЭЦП была выпущена УЦ, аккредитованным Минкомсвязи.

Следующее звено — КС удостоверяющего центра (промежуточный). Файл выдается в комплекте с ключами и содержит в себе:

• сведения об УЦ с указанием даты его действия;
• сервисный интернет-адрес (через который можно связаться с реестром компании).

Эти данные предоставляются в зашифрованном виде и используются криптопровайдером (на ПК пользователя) для проверки подлинности открытого ключа КЭЦП. Теоретически цифровую подпись можно украсть, но применить ее без установленного сертификата УЦ не получится. То есть вся ЦДС построена таким образом, чтобы предотвратить риски использования чужой подписи мошенниками.

СКПЭП — конечное звено в этой цепи. Его выдает удостоверяющий центр вместе с открытым и закрытым ключами. Сертификат предоставляется на бумажном или цифровом носителе и содержит основную информацию о держателе. Он связывает последовательность символов открытого ключа с конкретным лицом. Другими словами, СКПЭП подтверждает тот факт, что открытый ключ ЭП принадлежит определенному человеку.

Головной КС Минкомсвязи действует до 2036 года, а ПС удостоверяющих центров ликвидны в течение 12 месяцев, после чего необходимо скачать (или получить в УЦ) новый и переустановить его на свой ПК. Сертификат КЭЦП тоже действует не более 1 года, по истечении этого срока клиенту требуется получить новый.

Если возникает ошибка «Этот сертификат содержит недействительную цифровую подпись» , причина может быть в повреждении ЦДС от Минкомсвязи России до пользователя. То есть один из элементов в этой цепи искажен или изменен.

1. Задай вопрос нашему специалисту в конце статьи.
2. Получи подробную консультацию и полное описание нюансов!
3. Или найди уже готовый ответ в комментариях наших читателей.

Как решить проблему

В первую очередь стоит удостовериться, что КС корректно установлен и действителен. Для этого используется стандартный путь: «Пуск» → «Все программы» → «КриптоПро» → «Сертификаты» → «Доверенные центры сертификации» → «Реестр». В открывшемся списке должен быть документ от ПАК «Минкомсвязь России». Если сертификат отсутствует или он недействителен, его нужно установить, следуя алгоритму:

1. Открыть загруженный файл на ПК.
2. Во вкладке «Общие» кликнуть «Установить».
3. Поставить флажок напротив строчки «Поместить в следующее хранилище».

Выбрать хранилище «Доверенные корневые центры сертификации».

Продолжить установку кнопкой «ОК» и подтвердить согласие в окне «Предупреждение о безопасности».

После установки появится сообщение, что импорт успешно завершен. Далее рекомендуется перезагрузить компьютер.

Файл выдается удостоверяющим центром вместе с другими средствами для формирования ЭЦП. Если он утерян или удален, следует обратиться в УЦ, в котором был получен СКПЭП.

Если КС Минкомсвязи на месте, но в статусе по-прежнему сказано, что он недействителен, удалите его (выбрать файл и нажать «Удалить») и установите заново.

На форуме CryptoPro CSP предлагается еще один вариант решения проблемы. Но работает он не всегда. Если установка документа не помогла, откройте меню «Пуск» и выполните поиск редактора реестра по его названию regedit. В редакторе найдите и вручную удалите следующие ветки:

Не все ветки могут быть в наличии. Удалите те, что есть, предварительно сохранив их резервные копии в отдельный файл. Перезагрузите ПК и проверьте статус СКЭП — он должен стать действительным.

Важно! Удаление и редактирование ключей реестра может нарушить работоспособность системы, поэтому процедуру лучше доверить техническому специалисту.

Этот сертификат содержит недействительную цифровую подпись : устранение ошибки на примере казначейства

Самая распространенная причина недействительности сертификата заключается в нарушенных путях сертификации. Причем проблема может быть не только в файле Минкомсвязи, о котором было сказано ранее, но также в промежуточных и личных СКЭП. Рассмотрим эту причину на примере Управления Федерального казначейства (УФК), которое, среди прочего, тоже занимается выдачей КЭЦП.

Этот сертификат содержит недействительную цифровую подпись: изменение, повреждение файла УФК

Функции УЦ выполняются в территориальных органах Росказны по всей России. Для организации аукционов и размещения информации по закупкам для госнужд в интернете муниципальные и госзаказчики должны заверять отчеты ЭП, полученной в УФК.

Если не удается заверить документ ЭП казначейства , и появляется отметка « Этот сертификат содержит недействительную цифровую подпись », предлагается следующий алгоритм действий:

1. Перейти в папку «Личное».
2. Выбрать СКЭП, который не работает, и перейти во вкладку «Путь сертификации». В качестве головного УЦ будет указан Минкомсвязи РФ, а промежуточного (подчиненного) — Федеральное казначейство. Нижним звеном в этой цепи будет личный СКЭП держателя.
3. Если в поле состояния стоит статус недействительности документа, необходимо отследить всю цепочку и выявить «слабое звено».
4. Вернуться в раздел «Общие», чтобы убедиться, верно ли указаны сведения о компании, выпустившей СКЭП.
5. Выйти из папки «Личное» и перейти в хранилище «Промежуточные центры сертификации».

Если причина именно в этом звене, на вкладке «Общие» отобразятся сведения: «Этот сертификат не удалось проверить, проследив его до . ». Значит на этом участке обрывается путь.

1. Зайти в раздел «Корневые сертификаты» на веб-ресурсе УФК.
2. Скачать файл «Сертификат УЦ Федерального казначейства ГОСТ Р 34.10-2012».
3. Импортировать файл на ПК. Процесс импорта аналогичен описанной выше процедуре для головного центра, только в качестве хранилища необходимо выбрать «Промежуточные центры сертификации».
4. Перезагрузить компьютер.

На завершающем этапе необходимо перейти в папку «Личное», выбрать нужный СЭП и проверить путь сертификации. Если проблема с промежуточным звеном решена, в графе состояния будет стоять «Этот сертификат действителен». Это означает, что система проверила ЦДС для этого ключа и не выявила никаких ошибок.

Истечение срока

При наступлении нового календарного года пользователь должен установить обновленный промежуточный ключ УЦ на каждый компьютер, где используется КЭП. Операционная система выдаст соответствующее упоминание при запуске. Если не выполнить обновление вовремя, при заверке документов тоже будет возникать уведомление о недействительности ключа. Процедура установки аналогична рассмотренной ранее. Предыдущий ПС удалять необязательно, система все равно будет отмечать его как недействительный.

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

Источник