Отказ в приеме документов, используется недействительная машиночитаемая доверенность. : ЕГАИС в опте и рознице

Не вопрос для обсуждения, а скорее как памятка будущим поколениям.))
Сегодня столкнулся с таким ответом от ЕГАИС "Отказ в приеме документов, используется недействительная машиночитаемая доверенность. Просьба убедиться, что используемая вами доверенность действительна по сроку действия и ранее не была отозвана."
При этом УТМ переустанавливается, нормально запускается, все галочки зелёные. Отчёты туда-сюда летают, но документооборот не работает с этой ошибкой, т.е. не отправляются акты, ттнки и др документы. УТМ 2562.
Всё перепроверил в доверенности - всё нормально. Полез в панель управления рутокен - РСА всё норм, а вот ГОСТ на физ.лицо - отозван.
Сейчас разбираемся, что с сертификатом, но факт такой - РСА норм, МЧД норм, сертификат ГОСТ на фл отозван, но ошибка при этом "недействительная МЧД".
Немного как-то странно, но вдруг у кого-то такое же ....

Обновите УТМ до 4.2.0_2571.
Эта ошибка билда 2562

Хмм, а перепрописать ФСРАР ..
Нам помогло

если вы подразумевали РСА, то смысл его переписывать, если на ГОСТе стоит статус "Отозван" и дата/время. Или у вас в панели ГОСТ тоже светился как отозванный?

Ключ я смотрел на ПК в панели управления рутокен. И к сожалению это Эвотор - там можно поставить только тот УТМ, который они дадут.

Что-то мне подсказывает, что подобного рода сообщения прилетают в УТМ со стороны РАРа, так что обновляй-не обновляй, они все равно прилетать будут.

Применительно в МЧД интерено другое, а именно - генерация RSA ключа. Процесс описывался тут:
https://olegon.ru/showthread.php?t=38487
и немного тут:
https://olegon.ru/showthread.php?t=38181&page=6

Суть. При выборе роли "ФЛ с МЧД" и указании файлов самой МЧД и ее подписи мы жмем "Продолжить". SPA УТМ-а шлет POST запрос в сам УТМ: /api/query/proxy/gateway/rsa/mchd/checkMchd. Да, это API УТМа и формально соответствующий раздел должен отображаться в сваггере УТМа но не отображается в виду наличия анотации @ApiIgnore на контроллере. Я как-то снимал такую анотацию через Java Agent, получал раздел в сваггере но не смог понять, что туда засылать



(0.05Мб)

УТМ проксирует запрос на https : //test-utm-nd.egais.ru:8445/reception/universal/gateway/rsa/mchd/checkMchd (в боевом контуре сервер иной, на суть не влияет), там МЧД проверяется и обратно выдется JSON со сведениями о том, кто выдал доверенность (а там дичь вроде innPrincipial и kppPrincipial - разрабы с Образцова 38 (или откуда там вы - организацию и так все знают), если вы это читаете - убейтесь ап стену или возьмите словарь и выучите: principial - принципиальный, principal - главный, он же - доверитель), включая идентификатор доверенности mchdId и список торговых объектов.

Далее с полученными реквизитами дергается эндпоинт УТМ для геренации сертификата. Суть в том, что единожды получив (и прихранив) mchdId и реквизиты торговых объектов, можно генерировать RSA уже после того, как доверенность истечет или будет отозвана - проверка доверенности происходит на 1 шаге и этот шаг можно пропустить т.к. все необходимое уже имеется. Разрабы с Образцова 38 (с известной конторы), убейтесь ап стену еще раз - меня мой отдел безопасности за такой, пардон, высер, распял бы.

И еще немного грустного. ЕГАИС как-то запоминает, для какого именно доверителя то или иное физ лицо создавало RSA и позволяет в следующий раз использовать сертификат этого же самого физ лица только уже в роли Руководитель ИП для создания RSA того же самого доверителя БЕЗ предъявления доверенности - этому, пардон, руководителю вываливается список торговых объектов доверителя, что позволяет создать RSA так же без предъявления доверенности (правда, один косяк все же есть - в реквизитах сертификата фсрар айди и кпп самого объекта, а инн и наиименование - от "руководителя" - т.е. получается у условного физ лица иванова ивана иваныча появляется кпп и фсрар айди торгового объекта запомненного егаисом доверителя). Хлопцы - убейтесь ап стену в третий раз! И своему отделу тестирования порекомендуйте сделать то же самое!!!

ИМХО эта фича как раз классная, если к ней прикрутить фоновую проверку действия МЧД и организации/ИП в ЕГРЮЛ (ИП) и ограничить срок действия такого "токена"

Чуть деформировавшись в области ИБ вы поймете, что ничего классного в ней нет. Доверенность может быть отозвана (обычно это делается не просто так), при этом доверенное лицо все еще сможет перевыпускать сертификаты RSA на продуктивном контуре, парализуя тем самым корректную с точки зрения доверителя работу торгового объекта. Более того, он с этим сертификатом сможет получать данные (те же ТТНки), к которым не должен иметь доступ и оказывать зловредное воздействие на нормальный ход процесса подтверждая те ТТН, которые не стоило подтверждать или отклоняя те, которые не стоило отклонять

А че это я шифруюсь с конторой-то? Московский филиал ФГУП ЦентрИнформ (на картинке ж в первой строке в имени пакета указано) - СТРАНА ДОЛЖДНА ЗНАТЬ СВОИХ ГЕРОЕВ

Он отвечает за УТМ (т.е. - за транспортный аспект (часть) ЕГАИС)
А за серверную часть (аспект) ЕГАИС - отвечает Питерский филиал этой конторы
(если я всё правильно помню со времён, когда форум РАР ещё существовал..)
Ну это так, для информации..