Validate signature error trust что это

Веб — сервис интеграции

Уважаемый участник рынка ДМДК!

Инструкция по работе с интеграционным сервисом
размещена в разделе «Для бизнеса».

Olga Kont,
Здравствуйте.
В РТФМ написано, что для тестирования на локалхосте в health блок

от до в реквесте соап надо вырезать.
Или Вы уже ломитесь с запросами в тестовый контур?

от до в реквесте соап надо вырезать.
Или Вы уже ломитесь с запросами в тестовый контур?

Тестовый health прекрасно работает и запросы с названием Send. у меня уходят: получаю massageID.

Но когда выполняю запросы с названием Check. (чтобы получить УИНы и прочее) то получаю эту ошибку Error validate signature : -1

1. Скорость обработки запроса зависит от множества факторов, запрос будет в любом случае обработан. В случаях если запрос еще не обработан в ответе «CheckReserveBatchUic» будет сообщение «message not found». В этом случае необходимо повторить запрос позже. Рекомендуется установить временной интервал между запросами ответа — не менее 60 сек.
Параметр «RequestData.country» должен быть код отличным от кода РФ в случаях импорта ювелирных изделий.

А если я правильно понимаю про «-1», то «-1 – нет поля data или signed в json;» © 190-191 страницы мана.
ЗЫ.
тестовый контур что-то глючит. я второй день пытаюсь создать там организацию, и на каждом шаге интернал егог.. Может и с этоим что-то связано..
ЗЗЫ.
Полистайте эту ветку приблизительно с 16 страницы и дальше. Там куча непонятных мне слов, а Вам, возможно, пригодится.

Источник

Проблемы с электронной подписью и способы их решения

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

Важно отметить, что большинство ошибок при работе с ЭЦП можно устранить в домашних условиях, без необходимости привлечения специалистов со стороны.

Какие виды ошибок ЭЦП бывают

Среди наиболее часто встречающихся ошибок в процессе подписания электронных документов электронной подписью выделяют три ключевых блока:

Проблема с подписанием ЭПЦ

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

• Закрытый ключ со съемного носителя (диска, флешки, Токена), не соответствует имеющемуся ключу открытого сертификата. Банальный человеческий фактор выбора не того носителя информации с ЭЦП. Если же «правильный» ключ утерян, придется обращаться в Удостоверяющий центр для перевыпуска.
• Недействительный сертификат. Чтобы устранить подобную ошибку потребуется переустановить открытый сертификат. Важно учитывать требования криптопровайдера (инструкции по необходимым действиям) для установки открытых сертификатов.
• Сертификат подписи определяется как не проверенный. Потребуется выполнить переустановку корневого сертификата, сформировавшего ЭП Удостоверяющего центра.

• Закончился срок действия криптопровайдера. Необходимо получить новый лицензионный ключ, позволяющий работать с программным обеспечением криптопровайдера. Информация запрашивается через УЦ, либо владельца ПО.
• Не виден сертификат на носителе. Помогает простая перезагрузка компьютера для устранения ошибка генерации.
• Алгоритм сертификата ЭЦП не поддерживается. Подобная ошибка может возникать при подписании электронной отчетности в налоговую. Потребуется переустановить КриптоПро CSP и проверить его на совместительство с имеющейся у вас на компьютере операционной системой.

Как проявляется данная ошибка и что сделать, чтобы исправить

Ошибка исполнения функции с информированием о невозможности подписать документ ЭЦП обычно появляется в момент подписания документа.

Система сразу выводит на экран уведомление о непредвиденной ошибке с кратким указанием причины ее возникновения.

Обычно для ее исправления требуются такие действия:

• проверка наличия, срока действия, подлинности сертификатов и выполнение их замены;
• выполнение проверки корректной работы операционной системы компьютера, ее обновление до минимальных допустимых параметров;

• проверка состояния съемного носителя закрытого ключа;
• выявление и устранение ошибок работы криптопровайдера.

Важно. Причина, из-за которой владелец ЭЦП не может нею воспользоваться, может быть комплексной. Поэтому, если не сработал один из предложенных вариантов, проверьте по другим направлениям.

Проблема с сертификатом

Распространенным явлением во время подписания электронных документов ЭЦП является получение уведомления, что системе не удалось получить доступ к сертификатам, пригодным для формирования подписи.

Здесь причины возникновения неисправности могут быть такими:

1. Пользователь не установил на свой ПК корневые сертификаты УЦ, осуществлявшего формирование и выдачу ЭЦП. Для устранения – скачать и установить на компьютер такой сертификат, либо прописать доступ к нему.
2. Система не видит личных сертификатов владельца ЭЦП. Выдаются одновременно с оформлением ЭП. Их необходимо загрузить на ваш ПК, и подтянуть в криптопровайдер. В дальнейшем можно загрузить через сайт УЦ. Устанавливаются и прописываются на рабочем месте, предназначенном для работы с ЭЦП. С незарегистрированным сертификатом вы не сможете осуществлять подписание электронных документов.
3. Информирование о невалидности сертификатов. Обычно такое возможно в случае, когда заканчивается срок действия сертификата, либо их отзывают. Потребуется обращаться в УЦ, выдавший ЭЦП, для уточнения статуса сертификатов подписи. В некоторых случаях помогает обновление сертификатов на компьютере пользователя. Сделать это можно вручную.

Что делать если не найден сертификат или не верен

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

Для устранения этой проблемы необходимо:

• проверить наличие такого сертификата на вашем ПК по пути: «Пуск» — дальше «Все программы» — после этого плагин «КриптоПро» — а уже там «Сертификаты»;
• дальше находим вкладку «Личное», выбираем «Сертификаты»;

• потребуется открыть не отображенный во вкладке сертификат и просмотреть его «Путь сертификации»;
• тут отображаются все цепочки сертификатов в порядке ранжирования. Важно чтобы напротив какого-то из них не стоял желтый, либо красный значок предупреждения. Если подобное присутствует – нажмите на сам сертификат и ознакомьтесь с ошибкой, что выдаст система;
• в зависимости от причины (обычно это окончание действия сертификата, либо не верифицирован) выполните ее устранение.

Чтобы устранить ошибку и перезагрузить отозванный сертификат потребуется выполнить несколько не сложных действий:

• в окне «Свойства браузера» откройте личный сертификат. Попасть туда можно через «Поиск» меню «Пуск». В открытом окошке ищите вкладку «Содержание», дальше вкладку «Сертификаты»;
• после этого во вкладке «Состав» потребуется выбрать позицию «Точки распространения списков отзывов»;
• в следующем блоке под названием «Имя точки распространения» необходимо выполнить копирование ссылки загрузки файла списка отзывов;
• переходя по указанной ссылке необходимо скачать и установить файл списка отзывов (CRL);
• дальше переходим по подсказкам «Мастера импорта сертификатов».

Следующей распространенной проблемой, когда компьютер не видит сертификат на носителе, является сбой в работе программных продуктов компьютера либо Токена (флешки). Обычно помогает простая перезагрузка ПК. Среди прочих популярных проблем этого направления можно выделить такие:

1. На носителе отсутствует драйвер, либо он установлен не корректно. Необходимо скачать последнюю версию драйвера с официального источника и установите его. Можно проверить работоспособность съемного носителя на другом ПК. В этом случае, если другой ПК нормально работает с носителем ЭЦП, переустановите драйверы на первом компьютере.
2. Система долго распознает носитель ЭЦП. Тут проблема в операционной системе. Ее потребуется обновить до минимального уровня, требуемого для работы с ЭЦП.
3. USB-порт работает не корректно. Попробуйте подсоединить Токен (флешку) через другой порт, либо на другом ПК, чтобы убедиться, что проблема не в носителе. Выполните перезагрузку компьютера.
4. Если Токин (флешка) не открывается ни на одном компьютере, значит проблема в носителе. Когда ключ был записан в единственном экземпляре на этот носитель – потребуется обращаться в УЦ для перевыпуска ЭЦП.

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

Проблемы при авторизации

Часто с подобными неприятностями сталкиваются владельцы ЭЦП, пытающиеся пройти регистрацию, либо авторизацию на различных электронных торговых площадках. Пользователю появляется уведомление, что его подпись не авторизирована.

Обычно проблема кроется:

1. Отсутствие регистрации. Потребуется попросту зарегистрироваться на избранном вами ресурсе.
2. Не зарегистрирован сертификат. Возникает после обновления ключа ЭЦП. Устраняется путем регистрации нового сертификата ключа ЭЦП.

В дальнейшем, при работе на самой электронной площадке и попытке подписать электронные документы, могут возникать дополнительные трудности, связанные с такими моментами:

1. Необходимости присоединиться к регламенту. Система не даст возможность полноценно работать, если вы не согласитесь с ее условиями.
2. Невозможность загрузить файл (файлы). Обычно это ошибка превышения размера информации, что допустима для загрузки. Просто смените формат разрешения файла, чтобы уменьшить его размер.
3. Требование использовать определенный браузер (определенную версию браузера). Это системные требования владельца площадки, которые необходимо соблюдать.
4. Проблемы со считыванием сертификатов. Потребуется проверить не просрочены ли ваши сертификаты, а также все ли они установлены на ПК.

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

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

Несоответствие программного продукта операционной системы и съемного носителя (флешки), либо повреждение флешки. Устраняется путем обновления операционной системы до минимально необходимой версии. В случае обнаружения повреждения флешки – может потребоваться перевыпуск ЭЦП удостоверяющим центром.

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

Хранение сертификатов в Windows (от 7 версии) осуществляется по адресу: C:UsersПОЛЬЗОВАТЕЛЬAppDataRoamingMicrosoftSystemCertificates

где вместо «ПОЛЬЗОВАТЕЛЬ» должно стоять наименование вашего ПК

Источник

Troubleshooting Signature validation errors

These signature validation errors are caused when the resource provider (not Azure AD) is unable to validate the signature of the token, either because the signing key could not be found or the signing key used was not able to validate the signature. This article will describe the most common scenarios and solutions. The concept and root cause is still the same and will continue to apply. Unfortunately, many developers and vendors implement their token validation differently.

First, get the access token being sent to the resource provider. We need to decode this to review (3) important claims:

You can decode access tokens using https://jwt.ms

Let’s get the easy one out of the way. If you send a Microsoft Graph access token to any other resource provider that’s not Microsoft Graph, you will get a Signature validation error. Only Microsoft Graph can validate these tokens. You will know if this is a Microsoft Graph token when taking a look at the “aud” claim and its value is one of the following:

• https://graph.microsoft.us
• https://graph.microsoft.us/
• https://graph.microsoft.com
• https://graph.microsoft.com/
• https://dod-graph.microsoft.us
• https://dod-graph.microsoft.us/
• 00000003-0000-0000-c000-000000000000

Make sure you are acquiring the correct access token for the resource provider and the “aud” claim is what the resource provider is expecting. The audience of access tokens is determined by the scope parameter that is sent in the request when acquiring access tokens. So if you want to get an access token for https://api.contoso.com, then the scope will look something like this: https://api.contoso.com/read

For more information about Azure AD and exposing your API

As for the other scenarios, the resource provider determines where to get the signing keys based on the OpenId Connect Metadata configuration and which signing key to use based on the “kid” claim in the access token. This is configured on the resource provider such as your custom built API or API Authentication layer. If you’re using a Microsoft Authentication library like MSAL or Microsoft Identity Web, the default is generally:

If you have configured a Tenant ID that is for example “e21bbca2-1b75-4dea-9e34-d3d95d2ec661” then the MetadataAddress would be:

If you configured a “Authority” that looks like https://login.microsoftonline.us/e21bbca2-1b75-4dea-9e34-d3d95d2ec661 then the MetadataAddress would be:

The OpenId Connect Metadata endpoint has a property that provides the location to the signing keys. This is the jwks_uri also known as the discovery keys endpoint. So, depending on which OpenId Connect Metadata endpoint is used, it will return a URL for the jwks_uri. Here is a table that provides a few examples:

• Example 1:
  Metadata endpoint: https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration
  Discovery keys endpoint: https://login.microsoftonline.com/common/discovery/v2.0/keys

• Example 2:
  Metadata endpoint: https://login.microsoftonline.com/e21bbca2-1b75-4dea-9e34-d3d95d2ec661/v2.0/.well-known/openid-configuration
  Discovery keys endpoint: https://login.microsoftonline.com/e21bbca2-1b75-4dea-9e34-d3d95d2ec661/discovery/v2.0/keys

• Example 3:
  Metadata endpoint: https://login.microsoftonline.us/e21bbca2-1b75-4dea-9e34-d3d95d2ec661/v2.0/.well-known/openid-configuration
  Discovery keys endpoint: https://login.microsoftonline.us/e21bbca2-1b75-4dea-9e34-d3d95d2ec661/discovery/v2.0/keys

• Example 4:
  Metadata endpoint: https://login.microsoftonline.us/e21bbca2-1b75-4dea-9e34-d3d95d2ec661/v2.0/.well-known/openid-configuration?appid=06051593-1954-4e1f-a75f-7e5de243aeff
  Discovery keys endpoint: https://login.microsoftonline.us/e21bbca2-1b75-4dea-9e34-d3d95d2ec661/discovery/v2.0/keys?appid=06051593-1954-4e1f-a75f-7e5de243aeff

• Example 5:
  Metadata endpoint: https://contosob2c.b2clogin.com/contosob2c.onmicrosoft.com/b2c_1_susi/v2.0/.well-known/openid-configuration
  Discovery keys endpoint:https://contosob2c.b2clogin.com/contosob2c.onmicrosoft.com/b2c_1_susi/discovery/v2.0/keys

Our discovery keys endpoint may contain more than one signing key. So, if you’re manually looking for a specific key and not the signing key provided by the access token or your caching keys, your signature validation may fail as we do frequently rotate keys.

The content of our discovery keys endpoint will look something like this:

The “kid” claim in the access token needs to match one of the available keys available on the discovery key endpoint based on the “kid” property.

If the “kid” does not match between the “kid” on the access token and the keys available on the discovery endpoint, there are two possible reasons:

1. Azure AD and B2C uses different signing keys
2. The application is enabled for SAML SSO.

Next, we will take a look at the “iss” claim of the access token. For tokens issued by Azure AD, this will be one of the following values…

For tokens issued by Azure B2C, this will look something like this…

This is where it is really important to make sure your OpenId Connect Metadata configuration on the resource provider is configured correctly.

For tokens issued by Azure AD, make sure the OpenId Connect Metadata configuration looks something like this:

For more information regarding to Azure AD OpenId Connect configurations:

For tokens issued by Azure B2C, make sure the OpenId Connect Metadata configuration looks something like this:

For more information regarding to Azure B2C OpenId Connect configurations:

The application is enabled for SAML SSO.

Assuming the token is issued from Azure AD and not B2C, When an application in Azure AD is enabled for SAML SSO, the signing key used to sign tokens is the SAML signing certificate that was generated when SAML SSO was enabled.

Unfortunately, you can’t just disable SAML SSO to resolve this. This signing certificate can not be removed.

So when you look for the “kid” from the access token on the default discovery keys endpoint, usually “https://login.microsoftonline.com/common/discovery/v2.0/keys”, you may not see it listed. There are two solutions.

• Solution (1): Create a new app registration and do not enable SAML SSO (This is the recommended approach)

• Solution (2): This one is harder to implement and may not be possible depending on the resource provider. Resource provider will need to update its OpenId Connect Metadata configuration to include “?appid=”, so for example it would look something like this:
  https://login.microsoftonline.us/e21bbca2-1b75-4dea-9e34-d3d95d2ec661/v2.0/.well-known/openid-configuration?appid=06051593-1954-4e1f-a75f-7e5de243aeff

  Keep in mind is the application-id of the application in Azure AD.

Examples of where to configure OpenId Connect Metadata configurations

Make sure you set the OpenId Connect Metadata configuration based on whether the token is issued from Azure AD or Azure B2C or if you need to add “?appid=”

Generally if you configure the Azure AD instance and Tenant, or Authority correctly, this will resolve your issue.

Instance

For more information about Azure AD Instances:

Tenant

Tenant would be contoso.onmicrosoft.com

You can also use the Directory id or any verified domain. Its recommended to use the Directory ID or the initial domain provided by Azure AD (i.e. contoso.onmicrosoft.com).

If configuring a Authority, generally Instance and Tenant is not needed as Authority follows this format:

Generally the Metadata Address is built based on this Instance/Tenant/Authority configuration and will automatically concatenate “/.well-known/openid-configuration” at the end.

The following sections provide examples of manually specifying the Metadata Address.

Источник

4

ответов