Письмо Федеральной налоговой службы от 29 марта 2022 г. № КВ-4-25/3717@ “О направлении разъяснений по вопросам получения сведений, содержащихся в ЕРН, а также перехода субъектов РФ и муниципальных образований на использование сведений, содержащихся в ЕРН, в целях гармонизации государственных и муниципальных ресурсов”

Написал(а):

s.sokolko

3 года, 8 месяцев назад

(0 комментариев)

Система Межведомственного Электронного Взаимодействия или СМЭВ уже давно перестала быть инструментом исключительно для органов государственной власти. Подключение к СМЭВ доступно также и для некоторых коммерческих предприятий и организаций. Более того, в соответствии с Федеральным Законом подключение к СМЭВ является обязательным для удостоверяющих центров (которые выдают электронные подписи), банков, нотариусов и некоторых других коммерческих организаций. В частности, удостоверяющие центры в сответствии с 63-ФЗ осуществляют проверку достоверности сведений при выдаче электронной подписи с помощью инфраструктуры СМЭВ, а также регистрируют выдаваемые сертификаты в подсистеме СМЭВ-ЕСИА.

На момент написания статьи основной используемой версией системы является СМЭВ 2. Именно на данной версии функционирует большинство сервисов производственного контура (напрмер, сервис проверки паспортов МВД и сервис отправки сертификатов ЕСИА). Кроме того, активно запускается СМЭВ версии 3. Сервисы Федеральной Налоговой Службы (получение выписок из ЕГРЮЛ и ЕГРИП и т. ) и пенсионного фонда (проверка СНИЛС) уже доступны только через СМЭВ 3 без возможности работы по СМЭВ 2. Полный переход на СМЭВ 3 всех сервисов запланирован на 2019 год.

В преддверии нового года мы собрали наиболее полезные ссылки по переходу на работу с новой версией СМЭВ и особенностям СМЭВ 3.

Итак, приступм:

Базовая информация по СМЭВ: назначение и основные функции системы, архитектура: tadviser

2. Основные отличия СМЭВ 3 от СМЭВ 2 простыми словами: https://www.klerk.ru/bank/articles/419490/

3. Описание бесплатного адаптера для СМЭВ: https://hemulen-it.ru/2018/08/21/smev-adapter/ 

Наличие бесплатного адаптера СМЭВ является основным преимуществом СМЭВ 3. Он позволяет быстрее интегрировать свои системы со СМЭВ

4. Технологический портал СМЭВ3: https://smev3.gosuslugi.ru/portal/

Основной портал с официальной информацией по СМЭВ 3. Тут публикуются все руководящие документы, оповещения о регламентных работах и выладываются новые версии адаптера СМЭВ 3.

5. Пример интеграции на базе бесплатного адаптера СМЭВ: http://d-russia.ru/realizatsiya-smev-proekta-na-baze-besplatnogo-adaptera-smev.html

Одна из немногих статей в открытом доступе с успешным опытом взаимодействия со СМЭВ 3. Довольно подробно описываются технические подробности решения

6. Набитые шишки на новом СМЭВ http://d-russia.ru/shishki-nabitye-pri-rabote-s-adapterom-smev.html

Описывается негативный опыт работы с адаптером и его слабые стороны.

7. Переход на новый ГОСТ https://habr.com/company/alfa/blog/341476/

Полезная информация по подготовке к переходу на использование новых криптоалгоритмов, которые будут использоваться в СМЭВ 3. Обязательное использование нового ГОСТ планируется к запуску в 2019 году.

8. ЭП на Java и КриптоПРО для разработчиков https://habr.com/company/alfa/blog/350158/

Пример подписывания сообщений на Java через КриптоПРО для тех разработчиков, которые не планируют использовать готовый адаптер СМЭВ

9. Ветки форума КриптоПРО, посвящённые адаптеру СМЭВ3: https://www.cryptopro.ru/forum2/default.aspx?g=posts&m=95447 и https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=13683

10. Java модули ЭП СМЭВ3 https://github.com/vladk1m0/smevx-crypto

Свободная реализация модулей подписи на JAVA для разработчиков СМЭВ 2 и СМЭВ 3.

P.S. Также Вас может заинтересовать наш беспатный OpenSource Web-сервис для работы с Адаптером СМЭВ 3

Коллеги, всем добрый день!

Если есть у кого опыт взаимодействия, и советы, буду признателен

Вводные:

У нас возникла необходимость подключения организации к видам сведений Росреестра, через СМЭВ3.

Провели тестирование, и оказалось, что у Росреестра на 2021г и начало 2022г отсутствовала тестовая зона, о чем нам сообщила поддержка СМЭВ спустя полгода (насколько я знаю, на текущий момент, ситуация не изменилась).

Единственный вариант тестирования, это закидывание XML из эталона под форматы СМЭВ3, и вложения вы при этом не получите, т.к. СМЭВ3 их на тестовом контуре не выдаёт, ровно как и на продуктиве при проверке эталонов для подключения.

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

Подключили следующий вид сведений на продуктив: Прием обращений в ФГИС ЕГРН VS00376v004-RRTR02

Ссылка для ознакомления: https://smev3.gosuslugi.ru/portal/inquirytype_one.jsp?id=70074&zone=fed&page=1&dTest=false

После подключения начались безуспешные попытки формирования XML, для получения искомой выписки ЕГРН. Наш кейс достаточно простой, нам как организации, необходимо получить выписку ЕГРН по ЮЛ или ФЛ, путем указания кадастрового номера, соответственное запрос идет от организации.

Для этого мы используем тестовый сценарий №25: «Предоставление сведений, содержащихся в Едином государственном реестре недвижимости, посредством обеспечения доступа к федеральной государственной информационной системе ведения Единого государственного реестра недвижимости»

Т.к. у него в эталоне, именно такая выписка, которая нам нужна.

На протяжении длительного времени писали в разные поддержки, но в ответ либо молчание, либо «отфутболивание» друг на друга (СМЭВ на Росреестр и обратно, т.к. СМЭВ пишет, что не является поставщиком видов сведений Росреестра, а Росреестр в свою очередь отвечает, что поддержкой СМЭВ занимается сам СМЭВ)

Спустя время, мы отладили наши запросы из нашей ИС в СМЭВ (SendRequestRequest, GetResponseRequest)

Проверили отладку наших XML формируемых в СМЭВ, на странице СМЭВ, под версию сведений Росреестра (1.1)

Ссылка для ознакомления: https://smev3.gosuslugi.ru/portal/checkxmlform.jsp

Далее мы проверили отладку XML (app.xml, request.xml), которые формируются под схемы Росреестра

Полезная ссылка для верхнеуровневой отладки сообщений именно под схемы Росреестра (надеюсь кому-то поможет): https://pbprog.ru/webservices/xsd/

На выходе мы получается вот такое сообщение в статусе GetResponseResponse:

Успешно создано обращение с идентификатором Vedomstvo-2022-03-05-347453

Поддержка СМЭВ разводит руками, т.к. данное сообщение приходит от Росреестра

Поддержка Росреестра ответила конструктивно один раз за 1 год, и сообщило, что сообщение не проходит проверку на внутреннее заявление app.xml, т.е. «Не проходит проверку ФЛК», ошибку выдает только в системе Росреестра, а на шлюз СМЭВ приходит уже ответ: Успешно создано обращение с идентификатором Vedomstvo-2022-03-05-347453. Дополнительно закинули коллег сообщениями в поддержку с комментариями, по исправлению, но в ответ снова тишина.

Пояснить нам до сих пор не смогли по какой причине так происходит, и что надо исправить.

Прикладываю наш app.xml (отметил поля, которые мы заполняем). EgrnRequest и Declarant _id видоизменены как и уникальные данные исходного запроса.

Есть несколько вопросов:

1) Как должен выглядеть корректный app.xml по которому можно нормально запросить выписку по ЮЛ и ФЛ, от организации? Если у вас есть примеры, по которым данное сообщение работает, будет супер.

2) Корректный ли тестовый сценарий используется? Мы используем 25 сценарий. Но 24 и 25 сценарий различаются довольно странно, и выписки которые должен формировать Росреестр ответом – разные.

3) Как происходит оплата если используется взаимодействие ИС Организации – СМЭВ3- Росреестр? (вот этот момент коллеги, темный лес)

Подмечу, что используется электронная подпись СМЭВ, которая летит в исходном запросе для самого СМЭВ, и никаких дополнительных ключей Росреестр (accessKey, validKey, token и тому подобное) не выдавал. Предполагается, что при запросе через СМЭВ3, такие ключи не требуются, т.к. используется основной ключ СМЭВ3.

Если у вас тоже есть вопросы, постараюсь помочь со своей стороны

Федеральная налоговая служба в связи с поступающими обращениями субъектов Российской Федерации по вопросам получения сведений, содержащихся в федеральном регистре сведений о населении (далее – ЕРН), а также переходом органов государственной власти субъектов Российской Федерации и органов местного самоуправления на использование сведений, содержащихся в ЕРН, в целях гармонизации государственных и муниципальных ресурсов направляет следующие разъяснения.

1. Федеральная налоговая служба при исполнении полномочий оператора ФГИС “ЕРН” руководствуется Федеральным законом от 08.06.2020 N 168-ФЗ “О едином федеральном информационном регистре, содержащем сведения о населении Российской Федерации” (далее – Федеральный закон N 168-ФЗ).

Предоставление сведений из ЕРН регламентировано статьей 11 Федерального закона N 168-ФЗ, а также Правилами предоставления сведений из ЕРН, утвержденными постановлением Правительства Российской Федерации от 09.10.2021 N 1723 (далее – Правила предоставления сведений из ЕРН). Указанными нормативными правовыми актами определены перечень получателей сведений из ЕРН с учетом целей их использования, основания предоставления сведений, способы и сроки предоставления сведений, а также перечни (состав) предоставляемых сведений.

В соответствии с частями 2 и 6 статьи 11 Федерального закона N 168-ФЗ предоставление сведений из ЕРН осуществляется оператором в электронной форме посредством использования единой системы межведомственного электронного взаимодействия (далее – СМЭВ).

В соответствии с пунктом 2 части 1 статьи 11 Федерального закона N 168-ФЗ органы государственной власти субъектов Российской Федерации и органы местного самоуправления имеют право на получение сведений из ЕРН для использования в следующих целях:

– совершенствования предоставления государственных и муниципальных услуг и выполнения государственных и муниципальных функций, в том числе в электронной форме (с 01.01.2023);

– реализации государственной политики в сфере социально- экономического развития, защиты прав и законных интересов граждан Российской Федерации и иностранных граждан, находящихся в Российской Федерации, а также обеспечения национальной безопасности Российской Федерации (с 01.01.2024 обезличено);

– обеспечения актуальности и достоверности информационных ресурсов органов государственной власти субъектов Российской Федерации и органов местного самоуправления, содержащих сведения о населении Российской Федерации, и обеспечения возможности выявления изменений, содержащихся в них сведений о населении Российской Федерации путем приведения указанных сведений в соответствие со сведениями, содержащимися в ЕРН (с 01.01.2023, далее – гармонизация государственных и муниципальных ресурсов с ЕРН);

– реализации полномочий субъектов Российской Федерации по предметам совместного ведения Российской Федерации и субъектов Российской Федерации и по предметам ведения субъектов Российской Федерации, полномочий Российской Федерации, переданных субъектам Российской Федерации, а также полномочий органов местного самоуправления для решения вопросов местного значения (с 01.01.2024 обезличено);

– составления и реализации государственных и муниципальных программ, подготовки проектов бюджетов бюджетной системы Российской Федерации и в иных целях государственного и муниципального управления (с 01.01.2024 обезличено).

Пунктом 11 Правил предоставления сведений из ЕРН установлено, что предоставление сведений органам государственной власти субъектов Российской Федерации, органам местного самоуправления может осуществляться посредством соответствующих информационных систем органов исполнительной власти субъекта Российской Федерации, осуществляющих полномочия в сфере информационно-коммуникационных технологий и организации информационного взаимодействия с федеральными органами исполнительной власти и (или) автоматизированными системами федеральных органов исполнительной власти (далее – органы ИКТ субъектов Российской Федерации).

Правилами предоставления сведений из ЕРН предусмотрено предоставление органам государственной власти субъектов Российской Федерации и органам местного самоуправления сведений с использованием видов сведений СМЭВ 3 в режиме директивных рассылок по признаку принадлежности адреса места жительства и места регистрации физического лица к территории соответствующего субъекта Российской Федерации на основании кода ОКТМО и в режиме “запрос- ответ” в рамках оказания государственных услуг. С учетом вступления в силу положений о предоставлении сведений из ЕРН с 01.01.2023 разработка соответствующих видов сведений запланирована ФНС России в 2022 году:

– директивная рассылка – октябрь 2022,

– режим “запрос-ответ” – ноябрь 2022.

Перечень (состав) предоставляемых сведений из ЕРН в режиме директивной рассылки определен приложением 2 к Правилам предоставления сведений из ЕРН, в режиме “запрос-ответ” – в приложении 1. Информация о регистрации видов сведений в тестовой среде СМЭВ 3 и возможности их тестирования будет доведена до органов ИКТ субъектов Российской Федерации официальным письмом дополнительно.

2. Сроки перехода субъектов Российской Федерации и муниципальных образований на использование сведений, содержащихся в ЕРН, в целях гармонизации государственных и муниципальных ресурсов с ЕРН, определены постановлением Правительства Российской Федерации от 12.10.2021 N 1738 – с 01.01.2021 по 31.12.2025. Пунктом 2 указанного постановления Правительства Российской Федерации органам государственной власти субъектов Российской Федерации и органам местного самоуправления рекомендовано в срок до 01.07.2022 разработать и утвердить планы-графики перехода на использование сведений, содержащихся в ЕРН, с учетом включения в указанные планы-графики мероприятий, предусматривающих с 01.01.2023 реализацию положений общих требований по приведению сведений о населении Российской Федерации, содержащихся в информационных ресурсах, в т.ч. органов государственной власти субъектов Российской Федерации и органов местного самоуправления в соответствие со сведениями, содержащимися в ЕРН, и порядка первоначального приведения таких сведений в соответствие со сведениями, содержащимися в ЕРН, на переходный период, утвержденных постановлением Правительства Российской Федерации от 22.07.2021 N 1248 (далее – Правила приведения в соответствие ресурсов).

Гармонизация государственных и муниципальных ресурсов с ЕРН предполагается в режиме “запрос-ответ”. Оператор государственного или муниципального ресурса с 01.01.2023 по имеющимся в его распоряжении сведениям о физическом лице (состав запроса определен пунктом 19 Правил предоставления сведений из ЕРН) сначала запрашивает в ЕРН номер записи о физическом лице (далее – ID ЕРН), сохраняет ID ЕРН в государственном или муниципальном ресурсе, а затем по ID ЕРН запрашивает из ЕРН сведения о самом физическом лице с указанием разделов, по которым требуется предоставление сведений в целях гармонизации или актуализации. В соответствии с Правилами приведения в соответствие ресурсов гармонизации подлежат все государственные и муниципальные ресурсы, за исключением ресурсов поставщиков сведений в ЕРН.

Форма плана-графика, в том числе, перечень мероприятий по переходу на использование сведений, содержащихся в ЕРН, и сроки их реализации, определяются субъектом Российской Федерации самостоятельно с учетом вышеизложенных разъяснений. Федеральная налоговая служба как оператор не уполномочена на разработку и доведение типовой формы плана-графика и перечня типовых мероприятий.

3. Дополнительно Федеральная налоговая служба сообщает, что в соответствии с Правилами функционирования ФГИС “ЕРН”, утвержденными постановлением Правительства Российской Федерации от 08.07.2021 N 1141, к декабрю 2022 года будет организован личный кабинет получателя сведений, доступ к которому будет осуществляться с использованием учетной записи ЕСИА должностного лица, привязанной к учетной записи органа государственной власти субъекта Российской Федерации или органа муниципального образования. В кабинете потребителя будет возможность протестировать подключение к видам сведений ЕРН в СМЭВ.

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

ФНС разъяснила порядок получения информации из федерального регистра сведений о населении (ЕРН). Также указано, что Правительством РФ установлены сроки перехода регионов и муниципалитетов на использование данных ЕРН – с 1 января 2021 г. до 31 декабря 2025 г.

К декабрю 2022 г. решено организовать личный кабинет получателя сведений, доступ к которому будет возможен с использованием учетной записи ЕСИА должностного лица. В кабинете потребителя можно протестировать подключение к видам сведений ЕРН в СМЭВ.

В настоящей статье представлена подробная инструкция по тестированию видов сведений в тестовой и продуктивной средах СМЭВ  с использованием бесплатного Адаптера СМЭВ.

Общее описание процесса тестирования

Процесс тестирования видов сведений разбивается на два этапа:

• тестирование в тестовой среде СМЭВ;
• тестирование в продуктивной среде СМЭВ.

Тестирование в тестовой среде СМЭВ производится с использованием эмуляторов информационных систем поставщиков данных и эталонных запросов, прилагаемых к описанию видов сведений на технологическом портале СМЭВ.

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

Эталонные запросы, эталонные ответы и правила XSL-преобразования описываются в Руководстве пользователя вида сведений.

Для того, чтобы эталонный запрос был переадресован эмулятору, необходимо включить в запрос элемент testMessage со значением true.

Тестирование в продуктивной среде СМЭВ производится с использованием реальных запросов к реальным информационным системам поставщиков.

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

В обычном режиме работы СМЭВ-адаптер не сохраняет сообщения в формате СМЭВ.

Для перевода СМЭВ-адаптера в отладочный режим необходимо установить параметр development.transport.persist.soap в значение true и перезапустить СМЭВ-адаптер.

Для СМЭВ-адаптера устаревшей версии параметр development.transport.persist.soap располагается в конфигурационном файле core.properties.

Для СМЭВ-адаптера текущей версии параметр development.transport.persist.soap устанавливается в интерфейсе администратора, в разделе «Настройка конфигурации адаптера».

Для перехода в этот раздел необходимо в меню выбрать пункт «Настройка конфигурации» и в открывшейся форме выбрать режим «Показать расширенные настройки» (см. рисунок).

В расширенном режиме необходимо развернуть раздел «Отладка» и установить флаг «Сохранение входящих/исходящих сообщений СМЭВ» (см. рисунок), после чего нажать кнопку «Сохранить».

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

Для этого необходимо в командной панели перейти в каталог установки СМЭВ-адаптера и выполнить команду adapter.exe restart (или sh adaper.sh restart для CentOS), а если СМЭВ-адаптер установлен как служба Windows, перезапустить службу из консоли управления службами.

СМЭВ-адаптер устаревшей версии можно перезапустить двумя способами:

• Перезагрузкой сервера (если запуск адаптера проиводится автоматически при загрузке ОС);
• Удалением процесса адаптера и повторным его запуском из консоли.

Второй вариант более предпочтительный, потому что после окончания тестирования необходимо восстановить значение параметра development.transport.persist.soap=false, и только после этого перезагружать сервер (или адаптер).

Для повторного запуска адаптера необходимо в консоли перейти в каталог установки адаптера и выполнить команду sh startup.sh.

Тестирование в тестовой среде СМЭВ

Диаграмма активностей процесса тестирования ВС в тестовой среде СМЭВ представлена на рисунке.

Подготовка тестового запроса

Тестовый запрос должен быть сформирован в формате СМЭВ-адаптера, т.е. в виде сообщения ClientMessage.

Структура ClientMessage для запроса представлена на рисунке.

Значение элемента itSystem должно соответствовать мнемонике информационной системы Потребителя. В тестовой среде СМЭВ мнемоники ИС участников взаимодействия имеют, как правило, суффикс «_3T», в отличие от продуктивной среды, где мнемоники оканчиваются на «_3S».

Содержимое эталонного запроса вида сведений должно быть вставлено в элемент MessagePrimaryContent.

Содержимое элемента RequestMetadata заполняется следующим образом:

Пример сообщения ClientMessage:

Размещение тестового запроса в каталоге OUT СМЭВ-адаптера

Местоположение каталога OUT зависит от версии СМЭВ-адаптера.

Созданные файлы с сообщениями ClientMessage необходимо разместить в каталоге OUT.

Запуск СМЭВ-адаптера

Если в момент размещения ClientMessage в каталоге OUT СМЭВ-адаптер уже запущен, то эти сообщения будут отправлены в СМЭВ сразу же после их размещения в указанном каталоге.

В противном случае требуется запустить СМЭВ-адаптер.

Для этого необходимо открыть консоль и перейти в ней в каталог установки СМЭВ-адаптера.

Адаптер устаревшей версии запускается из консоли командой startup.bat (или sh startup.sh для CentOS).

Адаптер текущей версии запускается из консоли командой adapter.exe start (или sh adapter.sh start для CentOS).

Поиск СМЭВ-сообщений запроса и ответа

Для поиска сообщений, соответствующих отправленному сообщению и полученному ответу, необходимо узнать, с каким messageID был отправлен запрос в СМЭВ.

Для этого нужно открыть найти сообщение в каталоге OUT/Sent по clientID:

Для поиска файлов по их содержимому необходимо включить соответствующий параметр в эксплорере Windows:

В найденном сообщении, в элементе MessageId, будет содержаться идентификатор сообщения, отправленного в СМЭВ:

Должны быть найдены три сообщения:

• {мнемоника}-{GUID}-{SendRequestRequest}-{SUCCESS} – отправка в СМЭВ;
• {мнемоника}-{GUID}-{SendRequestResponse}-{SUCCESS} – подтверждение от СМЭВ;
• {мнемоника}-{GUID}-{GetResponseResponse}-{SUCCESS} – ответ от СМЭВ.

Для последнего сообщения (GetResponseResponse) необходимо найти сообщение с опросом очереди (GetResponseRequest). Оно имеет тот же GUID в наименовании файла, что и сообщение GetResponseResponse).

Сообщения Ack, о которых упоминается в Регламенте подключения ИС Участника к СМЭВ и в письмах от Ситуационного центра, СМЭВ-адаптером не фиксируются! Но СЦ, будучи информирован об использовании Потребителем СМЭВ-адаптера, не настаивает на включении Ack в результаты тестирования.

Взаимодействие с СЦ СМЭВ

Четыре найденных сообщения в формате СМЭВ необходимо упаковать в архив со значащим именем (например, «MNEM01_3T-ЕГРЮЛ-Request0.zip») и направить в Ситуационный центр СМЭВ в виде результатов тестирования.

Если тестировалось несколько эталонных запросов (а обычно так и происходит), то по четыре СМЭВ-сообщения для каждого эталонного запроса размещаются в отдельных каталогах, соответствующих эталонным запросам, например, «Request0», «Request1» и т.д.

Затем эти каталоги упаковываются в один архив, например, «MNEM01_3T-ЕГРЮЛ.zip», который отправляется в СЦ СМЭВ.

Тестирование в продуктивной среде СМЭВ

Тестирование в продуктивной среде СМЭВ должно производиться на сервере, имеющем доступ к продуктивной среде СМЭВ.

В СМЭВ-адаптере должен быть включен режим сохранения отладочных сообщений в формате СМЭВ (см. п. 1), после чего СМЭВ-адаптер должен быть перезапущен.

Формат сообщения ClientMessage отличается от формата, приведенного в п. 2.1, отсутствием элемента testMessage:

Содержимое запроса к виду сведений должно соответствовать реальному объекту или субъекту, сведения о котором необходимо получить.

Если в качестве запроса использовать один из эталонных запросов, то в ответ вернется, скорее всего, сообщение reject с признаком отсутствия данных в ИС Поставщика.

Дальнейший процесс ничем не отличается от тестирования ВС в тестовой среде СМЭВ, описанного в п. 2.

После окончания тестирования необходимо отключить режим сохранения отладочных сообщений в формате СМЭВ и перезапустить СМЭВ-адаптер.

Также вы можете передать задачи организации СМЭВ-взаимодействия участникам нашего проекта. Качественная настройка СМЭВа и интеграция Адаптера с различными ИС — наш нехемульский долг.

Система межведомственного электронного взаимодействия (СМЭВ) задумывалась как цифровая среда предоставления услуг и исполнения государственных и муниципальных функций в электронной форме.

В настоящее время СМЭВ продолжает расширять свои возможности и вовлекать все большее количество участников взаимодействия.

Что оказалось как нельзя кстати, в том числе для коммерческих организаций, в частности банков, которые все больше стремятся перевести свои услуги в цифру и сериализовать процессы.

В этой статье мы поговорим о том, как своими силами подписать запросы и проверить электронные подписи ответов СМЭВ версии 3.0, и о паре интересных нюансов, с которыми пришлось при этом столкнуться.

Здравствуйте!

Может возникнуть вопрос. Почему своими силами? Когда для СМЭВ 3 есть целый Технологический портал, где

• опубликована вся документация и методические указания,
• есть раздел с часто задаваемыми вопросами,
• можно скачать актуальную версию библиотек клиента СМЭВ 3,
• предоставлены примеры полных конвертов сообщений с подписями,
• можно даже проверить онлайн свое сообщение или из примера на соответствие схемам сервиса СМЭВ и на предмет валидности его электронной подписи

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

По той простой причине, что уже есть собственная информационная система, работающая с форматами электронной подписи XMLDSig, XAdES, в которой применяются библиотеки проекта Apache Santuario, реализующие основные стандарты безопасности для XML. А также библиотеки, входящие в состав КриптоПро JCSP, помимо работы с XML, обеспечивающие API криптографических функций СКЗИ КриптоПро CSP.

Написание собственных методов для работы с электронными подписями СМЭВ 3 в данном случае выглядит более целесообразно, нежели разворачивание полного клиента поставляемого:
ФГБУ НИИ «Восход» (до 21 марта 2016 года ФГУП НИИ «Восход») или интеграция, его отдельных классов и пакетов.

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

Анализ исходных данных

Загружаем с портала СМЭВ 3:

• актуальную версию документа Методические рекомендации по работе с ЕСМЭВ версия 3.4.0.3
• примеры полных конвертов сообщений, отправляемых в СМЭВ 3

Если уже умеем формировать обычный XMLDSig или подписывать, например, конверты сообщений СМЭВ 2, то больше всего начинает интересовать, чем же отличается конверт с подписью СМЭВ 3 от СМЭВ 2.

Открываем пример конверта СМЭВ 3 SendRequestRequestNoAttach.xml

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1"> <S:Body> <ns2:SendRequestRequest xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"> <ns:SenderProvidedRequestData Id="SIGNED_BY_CONSUMER" xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:ns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1">	<ns:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns:MessageID><ns2:MessagePrimaryContent><ns1:BreachRequest xmlns:ns1="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0" xmlns:ns2="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0" xmlns:ns3="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1" Id="PERSONAL_SIGNATURE"> <ns1:RequestedInformation> <ns2:RegPointNum>Т785ЕС57</ns2:RegPointNum> </ns1:RequestedInformation> <ns1:Governance> <ns2:Name>ГИБДД РФ</ns2:Name> <ns2:Code>GIBDD</ns2:Code> <ns2:OfficialPerson> <ns3:FamilyName>Загурский</ns3:FamilyName> <ns3:FirstName>Андрей</ns3:FirstName> <ns3:Patronymic>Петрович</ns3:Patronymic> </ns2:OfficialPerson></ns1:Governance> </ns1:BreachRequest> </ns2:MessagePrimaryContent>	<ns:TestMessage/></ns:SenderProvidedRequestData> <ns2:CallerInformationSystemSignature><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411"/><ds:Reference URI="#SIGNED_BY_CONSUMER"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:Transform Algorithm="urn://smev-gov-ru/xmldsig/transform"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/><ds:DigestValue>/jXl70XwnttJB5sSokwh8SaVHwo2gjgILSu0qBaLUAo=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>J3746ks34pOcPGQpKzc0sz3n9+gjPtzZbSEEs4c3sTwbtfdaY7N/hxXzEIvXc+3ad9bc35Y8yBhZ/BYbloGt+Q==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIBcDCCAR2gAwIBAgIEHVmVKDAKBgYqhQMCAgMFADAtMRAwDgYDVQQLEwdTWVNURU0xMQwwCgYDVQQKEwNJUzIxCzAJBgNVBAYTAlJVMB4XDTE1MDUwNzEyMTUzMFoXDTE4MDUwNjEyMTUzMFowLTEQMA4GA1UECxMHU1lTVEVNMTEMMAoGA1UEChMDSVMyMQswCQYDVQQGEwJSVTBjMBwGBiqFAwICEzASBgcqhQMCAiMBBgcqhQMCAh4BA0MABEDoWGZlTUWD43G1N7TEm14+QyXrJWProrzoDoCJRem169q4bezFOUODcNooQJNg3PtAizkWeFcX4b93u8fpVy7RoyEwHzAdBgNVHQ4EFgQUaRG++MAcPZvK/E2vR1BBl5G7s5EwCgYGKoUDAgIDBQADQQCg25vA3RJL3kgcJhVOHA86vnkMAtZYr6HBPa7LpEo0HJrbBF0ygKk50app1lzPdZ5TtK2itfmNgTYiuQHX3+nE</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature></ns2:CallerInformationSystemSignature> </ns2:SendRequestRequest> </S:Body>
</S:Envelope>

Дедуктивным методом выясняется что:

• больше не используется прием с выносом из содержимого тега Signature в Security заголовок элемента BinarySecurityToken с сертификатом открытого ключа проверки электронной подписи и ссылкой на него через SecurityTokenReference в теле самого Signature, как, например, в СМЭВ 2.4.6. Теперь сертификат должен находиться внутри Signature.
• второе и, по сути, самое существенное и важное изменение, оказывающее большое влияние на процесс подписи — это добавление новой проприетарной трансформации:

  <ds:Transform Algorithm="urn://smev-gov-ru/xmldsig/transform"/>

Через эту трансформацию распространяются собственные правила каноникализации СМЭВ 3.

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

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

В поисках описания трансформации urn://smev-gov-ru/xmldsig/transform открываем Методические рекомендации 3.4.0.3

Знакомимся с пунктом 4.4.2.1 Правила формирования электронной подписи сообщений

Формат подписи XMLDSig detached (https://www.w3.org/TR/xmldsig-core/)

Трансформация, дополнительно к канонизации urn://smev-gov-ru/xmldsig/transform

Требования к форматированию В XML-структуре подписи между элементами не допускается наличие текстовых узлов, в том числе переводов строки.

Пункт Методических указаний 12.4. ПРИЛОЖЕНИЕ 4: ОБРАЗЦОВАЯ РЕАЛИЗАЦИЯ ТРАНСФОРМАЦИИ URN://SMEV-GOV-RU/XMLDSIG/TRANSFORM
содержит Java класс SmevTransformSpi.java, реализующий алгоритм трансформации «urn://smev-gov-ru/xmldsig/transform», наследник org.apache.xml.security.transforms.TransformSpi из библиотеки Apache Santuario.

Таким образом, чтобы обеспечить каноникализацию подписываемого конверта СМЭВ 3, можно использовать в своем коде этот класс трансформации.

Единственным условием и ограничением в этом случае будет, что для обработки XML-документа при формировании подписи или ее проверки нужно использовать именно org.apache.xml.security.signature.XMLSignature из проекта Apache Santuario.

Задействовать инструменты из пакетов javax.xml.crypto.dsig или ru.CryptoPro.JCPxml.xmldsig просто так уже не получится.

Подготовка к подписи по правилам СМЭВ 3

Apache Santuario изначально ничего не знает про ГОСТ криптографические алгоритмы и СКЗИ КриптоПро.

В библиотеке xmlsec-1.5.0.jar в файле \org\apache\xml\security\resource\config.xml содержатся настройки только для работы с зарубежными криптографическими алгоритмами.

Чтобы он начал распознавать и применять ГОСТ, нужно выполнить его инициализацию.

По старинке это делалось так:

//APACHE-SANTUARIO INIT WITH CryptoPro JCP System.setProperty("org.apache.xml.security.resource.config", "resource/jcp.xml"); org.apache.xml.security.Init.init(); String cfile1 = System.getProperty("org.apache.xml.security.resource.config"); LOGGER.log(Level.INFO, "Init class URL: " + org.apache.xml.security.Init.class.getProtectionDomain().getCodeSource().getLocation()); LOGGER.log(Level.INFO, cfile1);

В новых версиях КриптоПро JCP (JCSP) инициализацию выполнит одна строчка:

ru.CryptoPro.JCPxml.xmldsig.JCPXMLDSigInit.init();

Теперь нужно Apache Santuario научить новым правилам трансформации, которые диктует СМЭВ 3. Для этого регистрируем класс трансформации:

 try { Transform.register(SmevTransformSpi.ALGORITHM_URN, SmevTransformSpi.class.getName()); santuarioIgnoreLineBreaks(true); LOGGER.log(Level.INFO, "SmevTransformSpi has been initialized"); } catch (AlgorithmAlreadyRegisteredException e) { LOGGER.log(Level.INFO, "SmevTransformSpi Algorithm already registered: " + e.getMessage()); } 

Заодно сразу выполняем требование из Методических указаний:

Требования к форматированию В XML-структуре подписи между элементами не допускается наличие текстовых узлов, в том числе переводов строки.

santuarioIgnoreLineBreaks(true); private static final String IGNORE_LINE_BREAKS_FIELD = "ignoreLineBreaks";
/** * Apache Santuario privileged switch IgnoreLineBreaks property * * @param mode */ private void santuarioIgnoreLineBreaks(Boolean mode) { try { Boolean currMode = mode; AccessController.doPrivileged(new PrivilegedExceptionAction<Boolean>() { public Boolean run() throws Exception { Field f = XMLUtils.class.getDeclaredField(IGNORE_LINE_BREAKS_FIELD); f.setAccessible(true); f.set(null, currMode); return false; } }); } catch (Exception e) { LOGGER.warning("santuarioIgnoreLineBreaks " + ExceptionUtils.getFullStackTrace(e)); } }

Делается это в привилегированном блоке AccessController.doPrivileged
и через reflection, из-за особенности реализации свойства ignoreLineBreaks в Santuario.

Просто через настройку системного свойства:

System.setProperty("org.apache.xml.security.ignoreLineBreaks", "true");

не работает.

Через настройку опции JVM:

-Dcom.sun.org.apache.xml.internal.security.ignoreLineBreaks=true

работает.

Если взглянуть на код класса org.apache.xml.security.utils.XMLUtils, то можно увидеть, что поле ignoreLineBreaks статическое, инициализируется в привилегированном блоке из системного свойства «org.apache.xml.security.ignoreLineBreaks».

private static boolean ignoreLineBreaks = AccessController.doPrivileged(new PrivilegedAction<Boolean>() { public Boolean run() { return Boolean.valueOf(Boolean.getBoolean ("org.apache.xml.security.ignoreLineBreaks")); } }).booleanValue();
public static boolean ignoreLineBreaks() { return ignoreLineBreaks; }

Такая реализация приводит к невозможности гибко настроить в одном Java процессе для части методов игнорировать перевод строк, а для другой части не игнорировать.

Т.е., если одно приложение выполняет подписи XMLDsig, СМЭВ 2 и СМЭВ 3, все XML документы, обработанные Santuario должны на выходе лишиться перевода строк.

С этим свойством, конечно, возникает вопрос к Apache Santuario:

Подпись сообщений СМЭВ 3

Для подписи документов СМЭВ 3 все готово.

Код подписания выглядит следующим образом:

private static final String XMLDSIG_MORE_GOSTR34102001_GOSTR3411 = "http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411"; private static final String XMLDSIG_MORE_GOSTR3411 = "http://www.w3.org/2001/04/xmldsig-more#gostr3411"; private static final String CANONICALIZATION_METHOD = "http://www.w3.org/2001/10/xml-exc-c14n#"; private static final String DS_SIGNATURE = "//ds:Signature"; private static final String SIG_ID = "sigID"; private static final String COULD_NOT_FIND_XML_ELEMENT_NAME = "ERROR! Could not find xmlElementName = "; private static final String GRID = "#"; private static final String XML_SIGNATURE_ERROR = "xmlDSignature ERROR: ";
try { // инициализация объекта чтения XML-документа DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); // установка флага, определяющего игнорирование пробелов в // содержимом элементов при обработке XML-документа dbf.setIgnoringElementContentWhitespace(true); // установка флага, определяющего преобразование узлов CDATA в // текстовые узлы при обработке XML-документа dbf.setCoalescing(true); // установка флага, определяющего поддержку пространств имен при // обработке XML-документа dbf.setNamespaceAware(true);
// загрузка содержимого подписываемого документа на основе // установленных флагами правил из массива байтов data DocumentBuilder documentBuilder = dbf.newDocumentBuilder(); Document doc = documentBuilder.parse(new ByteArrayInputStream(data)); /* * Добавление узла подписи <ds:Signature> в загруженный XML-документ */ // алгоритм подписи (ГОСТ Р 34.10-2001) final String signMethod = XMLDSIG_MORE_GOSTR34102001_GOSTR3411; // алгоритм хеширования, используемый при подписи (ГОСТ Р 34.11-94) final String digestMethod = XMLDSIG_MORE_GOSTR3411; final String canonicalizationMethod = CANONICALIZATION_METHOD; String[][] filters = {{XPath2FilterContainer.SUBTRACT, DS_SIGNATURE}}; String sigId = SIG_ID; // инициализация объекта формирования ЭЦП в соответствии с // алгоритмом ГОСТ Р 34.10-2001 XMLSignature sig = new XMLSignature(doc, "", signMethod, canonicalizationMethod); // определение идентификатора первого узла подписи sig.setId(sigId); // получение корневого узла XML-документа Element anElement = null; if (xmlElementName == null) { anElement = doc.getDocumentElement(); } else { NodeList nodeList = doc.getElementsByTagName(xmlElementName); anElement = (Element) nodeList.item(0); } // = doc.getElementById("#AppData"); // добавление в корневой узел XML-документа узла подписи if (anElement != null) { anElement.appendChild(sig.getElement()); } else { throw new SignatureProcessorException(COULD_NOT_FIND_XML_ELEMENT_NAME + xmlElementName); } /* * Определение правил работы с XML-документом и добавление в узел подписи этих * правил */ // создание узла преобразований <ds:Transforms> обрабатываемого // XML-документа Transforms transforms = new Transforms(doc); // добавление в узел преобразований правил работы с документом // transforms.addTransform(Transforms.TRANSFORM_ENVELOPED_SIGNATURE); transforms.addTransform(Transforms.TRANSFORM_C14N_EXCL_OMIT_COMMENTS); transforms.addTransform(SmevTransformSpi.ALGORITHM_URN); // добавление в узел подписи ссылок (узла <ds:Reference>), // определяющих правила работы с // XML-документом (обрабатывается текущий документ с заданными в // узле <ds:Transforms> правилами // и заданным алгоритмом хеширования) sig.addDocument(xmlElementID == null ? "" : GRID + xmlElementID, transforms, digestMethod); /* * Создание подписи всего содержимого XML-документа на основе закрытого ключа, * заданных правил и алгоритмов */ // создание внутри узла подписи узла <ds:KeyInfo> информации об // открытом ключе на основе // сертификата sig.addKeyInfo(x509Cert); // создание подписи XML-документа sig.sign(privateKey); // определение потока, в который осуществляется запись подписанного // XML-документа bais = new ByteArrayOutputStream(); // инициализация объекта копирования содержимого XML-документа в // поток TransformerFactory tf = TransformerFactory.newInstance(); // создание объекта копирования содержимого XML-документа в поток Transformer trans = tf.newTransformer(); // копирование содержимого XML-документа в поток trans.transform(new DOMSource(doc), new StreamResult(bais)); bais.close(); } catch (TransformationException e) { throw new SignatureProcessorException("TransformationException " + XML_SIGNATURE_ERROR + e.getMessage()); } catch (XMLSignatureException e) { throw new SignatureProcessorException("XMLSignatureException " + XML_SIGNATURE_ERROR + e.getMessage()); } catch (TransformerException e) { throw new SignatureProcessorException("TransformerException " + XML_SIGNATURE_ERROR + e.getMessage()); } catch (IOException e) { throw new SignatureProcessorException("IOException " + XML_SIGNATURE_ERROR + e.getMessage()); } catch (XMLSecurityException e) { throw new SignatureProcessorException("XMLSecurityException " + XML_SIGNATURE_ERROR + e.getMessage()); } catch (SAXException e) { throw new SignatureProcessorException("SAXException " + XML_SIGNATURE_ERROR + e.getMessage()); } catch (ParserConfigurationException e) { throw new SignatureProcessorException( "ParserConfigurationException " + XML_SIGNATURE_ERROR + e.getMessage()); } return bais.toByteArray();

Основными параметрами здесь являются:

byte[] data, // XML сообщение в виде массива байтов
String xmlElementName, // имя элемента в XML вместе с префиксом, в который следует добавить подпись, для СМЭВ-3 в общем случае "ns2:CallerInformationSystemSignature"
String xmlElementID // ID элемента в XML (если присутствует) вместе с префиксом, на который следует поставить подпись, для СМЭВ-3 в общем случае "SIGNED_BY_CONSUMER"
X509Certificate certificate // сертификат открытого ключа проверки подписи
PrivateKey privateKey // закрытый ключ подписи

Проверка подписи сообщения СМЭВ 3

Код проверки подписи выглядит следующим образом:

private static final QName QNAME_SIGNATURE = new QName("http://www.w3.org/2000/09/xmldsig#", "Signature", "ds"); private static final String SIGNATURE_NOT_FOUND = "Signature not found!"; private static final String SIGNATURE_NOT_VALID = "Signature not valid"; private static final String SMEV_SIGNATURE_PASSED_CORE_VALIDATION = "SmevSignature passed core validation"; private static final String VERIFY_SIGNATURE_ON_XML_IO_EXCEPTION = "Verify signature on XML IOException: "; private static final String VERIFY_SIGNATURE_ON_XML_PARSER_CONFIGURATION_EXCEPTION = "Verify signature on XML ParserConfigurationException: "; private static final String VERIFY_SIGNATURE_ON_XML_SAX_EXCEPTION = "Verify signature on XML SAXException: "; private static final String VERIFY_SIGNATURE_ON_XML_XML_SIGNATURE_EXCEPTION = "Verify signature on XML XMLSignatureException: "; private static final String VERIFY_SIGNATURE_ON_XML_XML_SECURITY_EXCEPTION = "Verify signature on XML XMLSecurityException: "; private static final String ID = "Id"; boolean coreValidity = true; try { DocumentBuilderFactory bf = DocumentBuilderFactory.newInstance(); bf.setNamespaceAware(true); DocumentBuilder b = bf.newDocumentBuilder(); Document doc = b.parse(new InputSource(new ByteArrayInputStream(signedXmlData))); NodeList sigs = doc.getElementsByTagNameNS(QNAME_SIGNATURE.getNamespaceURI(), QNAME_SIGNATURE.getLocalPart()); org.apache.xml.security.signature.XMLSignature sig = null; sigSearch: { for (int i = 0; i < sigs.getLength(); i++) { Element sigElement = (Element) sigs.item(i); String sigId = sigElement.getAttribute(ID); if (sigId != null) { sig = new org.apache.xml.security.signature.XMLSignature(sigElement, ""); break sigSearch; } } throw new XMLSignatureVerificationException(SIGNATURE_NOT_FOUND); } org.apache.xml.security.keys.KeyInfo ki = (org.apache.xml.security.keys.KeyInfo) sig.getKeyInfo(); X509Certificate certificate = ki.getX509Certificate(); if (!sig.checkSignatureValue(certificate.getPublicKey())) { coreValidity = false; LOGGER.log(Level.INFO, SIGNATURE_NOT_VALID); } else { LOGGER.log(Level.INFO, String.format(SMEV_SIGNATURE_PASSED_CORE_VALIDATION)); } } catch (IOException e) { throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_IO_EXCEPTION + ExceptionUtils.getStackTrace(e)); } catch (ParserConfigurationException e) { throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_PARSER_CONFIGURATION_EXCEPTION + ExceptionUtils.getStackTrace(e)); } catch (SAXException e) { throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_SAX_EXCEPTION + ExceptionUtils.getStackTrace(e)); } catch (org.apache.xml.security.signature.XMLSignatureException e) { throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_XML_SIGNATURE_EXCEPTION + ExceptionUtils.getStackTrace(e)); } catch (XMLSecurityException e) { throw new XMLSignatureVerificationException(VERIFY_SIGNATURE_ON_XML_XML_SECURITY_EXCEPTION + ExceptionUtils.getStackTrace(e)); } return coreValidity;

Проблемы. Хэш не совпадает

Внимание!

Для отладки использовался пример конверта СМЭВ 3 SendRequestRequestNoAttach.xml
Из него был удален элемент ds:Signature с целью подписать сообщение заново и сверить с оригиналом.

Несмотря на то, что метод подписи и трансформация SmevTransformSpi, взятая из Методических указаний, отрабатывали, на выходе был подписанный документ, подпись которого при онлайн-проверке на портале СМЭВ 3 трактовалась как

ЭП-ОВ не подтверждена: Ошибка проверки ЭП: Нарушена целостность ЭП

Почему

<ds:DigestValue>e76oVeYGapFDE+PV6glsj0XDjLHydLMd0cSkFPY8fWk=</ds:DigestValue>

не совпадал с оригинальным примером:

<ds:DigestValue>/jXl70XwnttJB5sSokwh8SaVHwo2gjgILSu0qBaLUAo==</ds:DigestValue>

Для диагностики причин в класс SmevTransformSpi в метод process был добавлен свой XMLEventWriter.

ByteArrayOutputStream baos = new ByteArrayOutputStream();
XMLEventWriter bdst =
outputFactory.get().createXMLEventWriter(baos, ENCODING_UTF_8); 

для параллельного анализа всех этапов трансформации.

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

<ns1:SenderProvidedRequestData xmlns:ns1="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" Id="SIGNED_BY_CONSUMER"><ns1:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns1:MessageID><ns2:MessagePrimaryContent xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"><ns3:BreachRequest xmlns:ns3="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0" Id="PERSONAL_SIGNATURE"><ns3:RequestedInformation><ns4:RegPointNum xmlns:ns4="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">Т785ЕС57</ns4:RegPointNum></ns3:RequestedInformation><ns3:Governance><ns4:Name>ГИБДД РФ</ns4:Name><ns4:Code>GIBDD</ns4:Code><ns4:OfficialPerson><ns5:FamilyName xmlns:ns5="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Загурский</ns5:FamilyName><ns5:FirstName>Андрей</ns5:FirstName><ns5:Patronymic>Петрович</ns5:Patronymic></ns4:OfficialPerson></ns3:Governance></ns3:BreachRequest></ns2:MessagePrimaryContent><ns1:TestMessage></ns1:TestMessage></ns1:SenderProvidedRequestData>

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

Во-вторых, привел в GitHub, где был выложен класс SmevTransformSpi более старой версии.

Старая версия класса трансформации выдала следующий нормализованный документ:

<ns1:SenderProvidedRequestData xmlns:ns1="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" Id="SIGNED_BY_CONSUMER"><ns1:MessageID>db0486d0-3c08-11e5-95e2-d4c9eff07b77</ns1:MessageID><ns2:MessagePrimaryContent xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1"><ns3:BreachRequest xmlns:ns3="urn://x-artefacts-gibdd-gov-ru/breach/root/1.0" Id="PERSONAL_SIGNATURE"><ns3:RequestedInformation><ns4:RegPointNum xmlns:ns4="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">Т785ЕС57</ns4:RegPointNum></ns3:RequestedInformation><ns3:Governance><ns5:Name xmlns:ns5="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">ГИБДД РФ</ns5:Name><ns6:Code xmlns:ns6="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0">GIBDD</ns6:Code><ns7:OfficialPerson xmlns:ns7="urn://x-artefacts-gibdd-gov-ru/breach/commons/1.0"><ns8:FamilyName xmlns:ns8="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Загурский</ns8:FamilyName><ns9:FirstName xmlns:ns9="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Андрей</ns9:FirstName><ns10:Patronymic xmlns:ns10="urn://x-artefacts-smev-gov-ru/supplementary/commons/1.0.1">Петрович</ns10:Patronymic></ns7:OfficialPerson></ns3:Governance></ns3:BreachRequest></ns2:MessagePrimaryContent><ns1:TestMessage></ns1:TestMessage></ns1:SenderProvidedRequestData>

С ним хэш стал совпадать, а подпись успешно проходить валидацию.

Сравнение версий класса SmevTransformSpi показала, что помимо добавленных в новой реализации дополнительных функций логирования и диагностики в debug режиме:

if (logger.isDebugEnabled()) { debugStream = new DebugOutputStream(argDst); dst = outputFactory.get().createXMLEventWriter(debugStream, ENCODING_UTF_8); } else { dst = outputFactory.get().createXMLEventWriter(argDst, ENCODING_UTF_8); }

Класс из Методических указаний не содержит нужную строчку, или содержит опечатку:

Отсутствует строка:

prefixMappingStack.pop();

, которая удаляет первый объект из стека с префиксами

 Stack<List<Namespace>> prefixMappingStack = new Stack<List<Namespace>>();

, что приводило к неверной работе SmevTransformSpi.

Добавление этой строки в новую версию SmevTransformSpi.java решило проблему.

Работающий класс трансформации и конверт с подписью можно посмотреть в github.com/VBurmistrov/Smev3

Результаты

Подписание конвертов СМЭВ 3 выполняется успешно.

Сообщения проходят проверку на портале Электронного правительства Госуслуги

И в собственном приложении: