Sokolko
4 года, 9 месяцев назад
Как мы уже писали в статье про СМЭВ 3, Система Межведомственного Электронного Взаимодействия уже давно востребована не только государственным учреждениями и органами власти, но и рядом коммерческих организаций. У наших клиентов также возникла необходимость взаимодействия со СМЭВ. История взаимодействия была начата ещё во времена “расцвета” СМЭВ 2, для которой не было готового Адаптера СМЭВ (как для СМЭВ 3). В то время для взаимодействия со СМЭВ 2 нами был разработан собственный Адаптер СМЭВ. Он всё ещё остаётся актуальным для интеграции с некоторыми сервисами СМЭВ, которые остаются работать на СМЭВ 2 (например, отправка и регистрация сертификатов в ЕСИА для Удостоверяющих Центров). Ориентировочной датой переноса всех сервисов на СМЭВ 3 называют март 2019 года, но всё может круто поменяться, учитывая специфику функционирования СМЭВ. В данной статье речь пойдёт о запуске бесплатного Адаптера СМЭВ 3 для взаимодействия с ним.
Отличия СМЭВ 2 от СМЭВ 3
Изначально мы планировали доработать наш Адаптер СМЭВ 2 собственной разработки для взаимодействия со СМЭВ 3. Но, как выяснилось, отличия двух систем не просто значительные, а радикальные. По сути, с точки зрения интеграции СМЭВ 2 не имеет почти ничего общего со СМЭВ 3. В СМЭВ 2 каждый поставщик данных (ФНС, ПФР, МВД) имел свой SOAP-сервис со своим файлом WSDL и особенностями работы. В СМЭВ 3 присутствует единый сервис, который является посредником между запрашивающей стороной (нами) и поставщиками информации. Более детально СМЭВ 3 описан в документе Методические рекомендации по работе с ЕСМЭВ
При выборе способа интеграции нужно учитывать, что передаваемые сообщения подписываются электронной подписью (ЭП) организации. Кроме того, при взаимодействии с единым сервисом СМЭВ 3 нужно использовать протокол SOAP с нестандартным алгоритмом каноникализации. Не совсем понятно, почему разработчики СМЭВ решили использовать свою каноникализацию, это уже останется на их совести. Само собой, свободных и открытых библиотек для данного алгоритма нет. Трудности есть и с подписыванием запросов SOAP по ГОСТ, т.к. не все языки программирования поддерживают ГОСТ “из коробки”. Эталонная реализация алгоритма каноникализации доступна только на Java, так что разработчики, использующие другие языки должны либо реализовывать данный алгоритм самостоятельно, либо отказаться от работы со СМЭВ.
Кроме того, при работе с российскими криптоалгоритмами по ГОСТ, согласно требованиям нашего законодательства к защите ключа электронной подписи, необходимо использовать сертифицированный криптопровайдер. То есть просто экспортировать приватный ключ из носителя ЭП и подписывать им запросы технически можно, но запрещено требованиями регуляторов в данной сфере. Это тоже накладывает свои ограничения на выбор технологии интеграции. Учитывая все эти аргументы, у нас получилось 3 варианта интеграции со СМЭВ 3.
Полностью собственное решение на удобном нам языке (Python)
При таком подходе мы вынуждены экспортировать закрытый ключ в простой текстовый файл и защищать его каким-то образом. Для тестов такой вариант использовать можно, но для настоящего взаимодействия со СМЭВ нежелательно.
Реализация собственного адаптера на Java
Данный способ использует для хранения закрытой части ключа КриптоПРО JCP. Такое решение соответствует законодательным требованиям РФ по защите ЭП, т.к. используется сертифицированный криптопровайдер. К недостаткам можно отнести поддержку не всех носителей ЭП и необходимость приобретения лицензии на КриптоПРО JCP. Библиотека для Java распространяется свободно.
Мы решили не останавливаться на этом способе, т.к. он “прибит гвоздями” к Java, а для нас удобнее несколько иные технологии разработки.
Бесплатный Адаптер СМЭВ 3
Мы выбрали за основу последний способ. При данном подходе за взаимодействие со СМЭВ 3 отвечает бесплатный адаптер СМЭВ от Ростелекома. Он полностью реализует функции асинхронной работы с единым сервисом СМЭВ (постановка в очередь запросов и формирование ответов). Подпись вычисляется через Trusted Java, ключ хранится в стандартном КриптоПРО CSP, который поддерживает очень большое количество носителей ЭП и имеет все необходимые сертификаты. Тут следует отметить, что требуется приобретение лицензий на Trusted Java и КриптоПРО CSP, но они довольно бюджетные и не оказали существенного влияния на общую смету проекта (порядка 3 000 руб. суммарно).
На схеме цветом выделены те сервисы, которые реализуются непосредственно нами на удобной нам технологии разработки ПО (Python). Благодаря возможности выбора способа интеграции (база данных, файловый обмен, SOAP) мы не привязаны к Java или каким-либо другим языкам программирования. Более подробно интерфейсы интеграции Адаптера СМЭВ описаны в руководстве администратора Адаптера.
Подготовка к запуску
<img class="img-fluid" src="http://xn—-jtbajd3aso1dzd.xn--p1ai/static/media/uploads/risovach.ru_
.jpg” title=””>
В нашем случае, организация уже имела доступ к СМЭВ 2, была зарегистрирована в СМЭВ и имела все необходимые учётные записи. Но, как оказалось, для подключения к СМЭВ 3 этого недостаточно. Для получения учётной записи СМЭВ 3 необходимо снова собрать все документы и пройти процедуру подключения. Процедура описана в на Технологическом портале СМЭВ. После успешного подключения, на электронную почту будет направлено зарегистрированное наименование участника (название организации) и мнемоника, которая понадобится в дальнейшем для настройки Адаптера СМЭВ.
Выбор программной платформы для адаптера
Согласно официальной документации на Адатер СМЭВ 3, поддерживается как Windows, так и Linux. Это неудивительно, т.к. он написан на Java и изначально задумывался как кроссплатформенное программное обеспечение. Тем не менее, после более детального изучения документации, стало ясно, что поддержка Linux только номинальная. В частности, в руководстве администратора адаптера СМЭВ детально расписано, какие библиотеки для Java необходимо установить на Windows, представлены сведения о криптопровайдерах и т.д. В разделе об установке на Linux написано дословно “1. Развернуть и настроить java JRE в среде Linux.”. Это максимум информации, которую можно почерпнуть из официального руководства по вопросу установки на Linux. После нашего запроса в техподдержку пришла стандартная отписка, что нужно “настроить те же компоненты, что и в варианте с Windows”. После этого вопрос с выбором платформы был решён в пользу ОС Microsoft.
Установка адаптера СМЭВ
Для установки под Windows мы использовали полезную с технологического портала СМЭВ 3. Единственное. что следует учитывать: для настройки лицензии Trusted Java необходимо установить VC++ redistributable (из состава меню самой Trusted Java). Без неё окошко ввода лицензии не появляется. После установки и запуска адаптера он настраивается полностью по видеоинструкции на работу с тестовой средой (). Нужно не забыть настроить мнемонику системы и указать интеграцию через файловое хранилище (это потребуется дальше). Если планируется использовать web-интерфейс адаптера, рекомендую после установки сделать резервную копию машины: добавляемые в систему виды сведений никогда не удаляются. Такая уж особенность адаптера.
Тестовое взаимодействие со СМЭВ 3
Для того, чтобы иметь возможность работы с производственным контуром СМЭВ, необходимо обязательно пройти тестирование на тестовом контуре. Без соблюдения этого условия заявка на доступ к виду сведений будет сразу же отклонена. Тестирование предполагает отправку и получение эталонных запросов и ответов в адрес эмулятора СМЭВ. Результаты взаимодействия со СМЭВ по тестовому контуру отправляются в виде файлов с сообщениями адаптера как вложения к заявке на доступ к виду сведений. Для того, чтобы сообщения сохранялись в файлы, нужно в “Настройках конфигурации” Адаптера СМЭВ нажать кнопку “Показать расширенные настройки” и отметить галочку “12.2 Сохранение входящих/исходящих сообщений СМЭВ”
Будет загружен архив с несколькими файлами xml. Данные файлы представляют собой те сообщения, которые адаптер СМЭВ 3 должен отправить в адрес эмулятора и ответы на них.
Для того, чтобы отправить эталонные сообщения, нам необходимо подготовить файлы отправки. Т.к. мы выбрали интеграцию через файловое хранилище, адаптер будет забирать файлы из папки %ADAPTER_ROOT%integrationiles%MNEMONIC%out и на их основании отправлять сообщения. Тут проблема заключается в том, что у адаптера несколько иной формат конверта (сообщения), чем у сервиса ЕСМЭВ. Подробнее о формате можно почитать в руководстве администратора адаптера СМЭВ. Ниже приводится пример содержимого файла в формате адаптера для отправки эталонного сообщения тестирования вида сведений “Выписки из ЕГРЮЛ по запросам органов государственной власти”:
Здесь 111111 – мнемоника системы, 3e83e83a-6a23-4908-b0d2-e3ad08fe2602 – идентификатор запроса. Он должен меняться при каждом запросе. Можно воспользоваться онлайн-генератором по ссылке:
Как видно из примера, в блок MessagePrimaryContent помещается тело эталонного сообщения.
После отправки сообщения нужно подождать некоторое время и в папке %ADAPTER_ROOT%messages%MNEMONIC% появятся файлы, в которых будут находиться XML-сообщения запроса и ответа. Данные файлы следует сохранить и впоследствии прикрепить к заявке на доступ к виду сведений производственного контура СМЭВ. Операцию по тестированию следует повторить для всех эталонных сообщений в архиве.
После того, как были получены все необходимые XML-файлы, подключение к СМЭВ производственного контура становится делом техники: нужно только оформить соответствующую заявку на доступ к нужному ВС и приложить файлы тестирования. В нашем случае доступ был предоставлен в течение трёх дней.
Надеемся, наш опыт был Вам полезен. Удачи в работе со СМЭВ!
P. S. Также Вас может заинтересовать наш беспатный OpenSource Web-сервис для работы с Адаптером СМЭВ 3
Время на прочтение
Эта статья посвящена тому, как перестать использовать Крипто Про и перейти на Bouncy Castle в девелоперском/тестовом окружении.
В начале статьи будет больше про СМЭВ и его клиент, в конце — больше про конвертирование ключей с готовой копипастой, чтобы можно было начать прямо сейчас.
Картинка для привлечения внимания:
И сразу же ответ:
Disclamer
Конечно, сбежать с Крипто Про невозможно, потому что это оплот российской криптографии. Он удовлетовряет требованиям компетентных органов, он прописан в договоры и контракты, ему доверяет вся страна, и так далее. Поэтому все нижеописанное относится девелоперскому или тестовому окружению, где мы сами себе хозяева.
Недавно мне нужно было разобраться, как написать сервис, работающий с Системой Межведомственного Электронного Взаимодействия.
Все написанное представляет собой просто результат небольшого исследования, максимально абстрагированный от выполненной работы. И даже приблизительно угадать что-то о реально принятых решениях невозможно, я проверял.
Обоснование нужности готового клиента
На технологическом портале СМЭВ3 лежат исходники клиента, но вот незадача — они гвоздями прибиты к КриптоПро. Вордовский файл с инструкцией, приложенный к исходникам, утверждает это самым прямым образом. Да и все равно, исходные ключи у нас тоже в формате КриптоПро. Исходя из production это нормально, а вот для тестового окружения жутко неудобно. Хотелось бы от этого избавиться.
На сайте есть две версии — “актуальная” и “рекомендуемая”. Почему они так, и почему актуальная версия не рекомендуется, а рекомендуемая не актуальна — какая-то дилемма копирайтера 🙂 Дальше речь о том клиенте который “актуальный”.
Строго говоря, использовать его нельзя, потому что в архиве исходников нету текста лицензии, и поэтому непонятно, под какой лицензией должна распространяться производная работа. Я позвонил по телефону поддержки, написанному на портале, написал на почту, пару недель наблюдал как моя заявка летает между уровнями техподдержки и исполняющими организациями, и в результате воз и ныне там:
Несмотря на невозможность использовать его у себя непосредственно в коде, это отличный тестовый пример. Дело в том, что в методических рекомендациях СМЭВа без поллитры не разобраться, и готовый живой код дает отличный буст к пониманию.
Основная претензия к документации — это канцеляризмы и скудное описание в интернете.
Помните мем про копирайтера, который из абзаца сделал одно предложение в несколько слов? Для документации СМЭВа это имеет место быть, например вот цепочка рефакторинов для одной произовльно взятой фразы:
“2. И С потребителя направляет в СМЭВ межведомственный запрос;”
“2. И С потребителя направляет в СМЭВ запрос;”
“2. И С потребителя направляет запрос;”
“2. потребитель направляет запрос;”
“2. запрос потребителя;”
Короче, наличие готовой реализации — это добро.
Почему Крипто Про JCP добро
В качестве альтернативы в тестовом окружении я предалагю использовать Bouncy Castle с контейнером PKCS12 или JKS. Это открытое, свободное и бесплатное ПО.
К чести разработчиков Крипто Про, похоже, они принимали участие в его разработке.
Что нужно допилить в готовом клиенте, чтобы сбежать с Крипто Про
Код написан довольно дружелюбно для расширения, поэтому можно просто взять за основу класс KeyStoreWrapperJCP, и аналогично написать KeyStoreWrapperBouncyCastlePKCS12, KeyStoreWrapperBouncyCastleJKS.
Переписать DigitalSignatureFactory, так, чтобы он на вход начал принимать путь до криптоконтейнера на файловой системе и пароль от него (для КриптоПро это просто не нужно). Там есть свич, который проверяет тип криптопровайдера, в него надо дописать дополнительно два кейса, для имен типа BOUNCY_JKS и BOUNCY_PKCS12 и навешать использование соответсвующих KeyWrapper и вызов initXmlSec.
В initXmlSec нужно дописать
1) возможность принимать вообще любой провайдер, а не только криптопро (это просто удобно)
2) Security.addProvider(new BouncyCastleProvider());
3) для XMLDSIG_SIGN_METHOD сделать свич: если КриптоПро, то алгоритм называется “GOST3411withGOST3410EL”, а если BouncyCastle алгоритм называется “GOST3411WITHECGOST3410”.
Ну вроде как и все. Если бы была известна лицензия на этот смэв-клиент, я бы приложил конкретный код под Apache License 2, а так это просто список идей.
Инициализация XML-подписи в Santuario
Ах да, тут есть один интересный момент. В сети множество советов, касающихся СМЭВа, заключающихся в ручном парсинге кусков XMLек, и прочим закатом солнца вручную, но это не наш метод (и не метод, который использовали создатели клиента)
Замес в том, что сгенерить самоподписанные ключи по госту легко (копипаста на SO ищется за секунды). А вот подписать — нет, ибо по мнению интернет-школьников якобы Bouncycastle не поддерживает xml-подпись. Конкретней, при работе с Apache Santuario, XMLSignature из santuario-xmlsec не понимает что использовать для обработки метода “xmldsig-more#gostr34102001-gostr3411” при вызове xmlSignature.sign(privateKey).
Отдельная хохма в том, что IntelliJ IDEA Community глючит при попытке отдебажить xmlsec, бросая step in отладчика в неверное место верных исходников. Я попробовал все разумные версии Идеи, поэтому понимать как это работает надо вслепую, написуя тактические письма в Спортлото. Это не в укор Идее, не существует идеальных инструментов, просто фактор повлиявший на скорость понимания вопроса.
Чтобы это заработало, нужно:
1) Заимплементить реализацию SignatureAlgorithmSpi из Apache Santuario. В GetEngineUri вернуть строку: “http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411” (или что там у вас). Это ключевая магия. Совершенно ничего умного этот класс делать не должен.
Инициализация раз за всю жизнь приложения (н-р в синглтон-бине спринга):
2) Загрузить провайдер, чтобы не патчить JDK:
3) Впердолить в рантайм только что написанный класс:
String algorithmClassName = “fully qualified name класса реализующего SignatureAlgorithmSpi”;
Class.forName(algorithmClassName);
SignatureAlgorithm.providerInit();
SignatureAlgorithm.register(“http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411”, algorithmClassName);
4) Достучаться до маппингов алгоритмов JCE:
String ns = “http://www.xmlsecurity.org/NS/#configuration”;
Document document = DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
Element rootElement = document.createElementNS(ns, “JCEAlgorithmMappings”);
Element algorithms = document.createElementNS(ns, “Algorithms”);
5) Замапить метод на алгоритм:
Element aElem = document.createElementNS(NameSpace, “Algorithm”);
aElem.setAttribute(“URI”, “http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411”);
aElem.setAttribute(“Description”, “GOST R 34102001 Digital Signature Algorithm with GOST R 3411 Digest”);
aElem.setAttribute(“AlgorithmClass”, “Signature”);
aElem.setAttribute(“RequirementLevel”, “OPTIONAL”);
aElem.setAttribute(“JCEName”, “GOST3411WITHECGOST3410”);
algorithms.appendChild(aElem);
6) Применить маппинги:
6) PROFIT!
После этого XMLSignature резко начинает понимать этот метод, и начнет делать xmlSignature.sign.
Подготовка OpenSSL для работы с ГОСТ
Если у вас в начале статьи на стене висит OpenSSL, когда-нибудь он точно выстрелит.
Так что да, это важный момент, необходимый для осуществления дальнейшего текста.
Как мы можем попросить Крипто Про отдать ключи (на самом деле, нет)
Если у нас уже есть настоящие (не самоподписанные) ключи, то совершенно некисло было бы проверить их в действии. Да, мы говорим о тестовых целях, но таки доверяй — но проверяй!
Если поставить винду в виртуальную машину, накатить туда Крипто Про, установить ключи и попробовать их экспортировать, то обнаруживаем удивительную вещь: в экспортере не работает экспорт в PKCS12, а все остальные направления в экспортере заблокированы (англ. “grayed out”).
“От Алексея Писинина был получен ответ:
Добрый день. P KCS12 не соответствует требованиям безопасности ФСБ в части хранения закрытых ключей. В теории, закрытые ключи должны храниться на так называемых “съемных” носителях. Собственно, по этой причине и не работает экспорт.”
Я правильно это читаю как, что у них гуй для экспорта есть, но бизнес-логики к нему нету?!
Ппоэтому каких галочек ни нащелкай — всегда будет выпадать ошибка на последнем шаге гуевого мастера?!
Какой же стыд.
Dear God,
Please kill them all.
Love, Greg.
Как мы можем грубо заставить Крипто Про отдать ключи
Можно очень долго мучиться, пытаясь засучив C++ вычитать ключ из контейнера с помощью OpenSSL и такой-то матери. Я честно пытался, и разбился об задачу как корабль об скалы (по крайней мере, это задачка больше чем на 1 день для человека, который давно таким не занимался). На просторе интернетов мы не единственные, кто разбился об те же скалы: http://gigamir.net/techno/pub903517
Вот тут наступает момент “это радость со слезами на глазах”. Некая контора под названием Лисси Софт, всего за 2 тыщи рублей отдает нам гениальную утилиту P12FromGostCSP. Ее создатели таки победили ту проблему, которую не осилило сообщество, и она выдирает ключи в PFX. Радость — потому что она работает.
Со слезами — потому что это проприетарщина, и она фиг знает как работает.
На картинке Ричард Столлман как бы удивляется и спрашивает: “неужели вы боретесь с проприетарщиной с помощью другой проприетарщины?”
Так что целиком инструкция по перегону ключей выглядит как-то так:
Тестовые самоподписанные ключи
Так как мы деламем все это в тестовых целях, теперь мы подходим к кульминации и начинаем сами себе выдавать ключи.
Как выдать ключи в формате Крипто Про, я особо не заморачивался, потому что это просто не нужно в рамках текущей задачи. Но на всякий случай, существует сервис выдачи таких ключей: http://www.cryptopro.ru/certsrv/
Выдача контейнера JKS
Этот вопрос широко представлен в интернете, поэтому можно сразу смотреть Stackoverflow:
http://stackoverflow.com/questions/14580340/generate-gost-34-10-2001-keypair-and-save-it-to-some-keystore
Идея в том, что раз уж мы все равно используем Bouncy Castle, то им же можем и сгенерить ключ.
Этот код не самый идеальный, но дает реально работающую реализацию (на практике у меня в результате получилось несколько объемных классов, чтобы сделать удобный интерфейс)
Выдача контейнера PKCS12
В принципе, это не особо нужно, потому что у нас уже есть простой и удобный способ выдавать JKS, а JKS для Java это самое что ни на есть родное решение. Но для полноты картины, пусть будет.
Резюме
В результате всех вышеописанных действий мы получили относительно легий способ избавиться от тяжкой ноши Крипто Про.
В дальнейшем хотелось бы продолжить борьбу за выпил до финальной победы: оформить все утилиты, генераторы ключей, самописные смэв-клиенты итп в виде одного репозитория на Гитхабе. Еще, очень хотелось бы получить права на модификацию и распространение под пермиссивной лицензией официального клиента СМЭВ. Тогда половина этой статьи была бы просто не нужна, и проблема решалась бы скачиванием нужного кода с Гитхаба.
Недавно в этом блоге мы открыли тему интеграции со СМЭВ с использованием наших продуктов. Прошлая статья посвящена разработке на платформе . NET.
Для запуска примера необходимо:
Входящее сообщение выглядит так:
Предварительно нужно выполнить инициализацию сервис-провайдера для подписи XML:
Загружаем необходимые для работы данные (ключ, сертификат, сообщение):
// Инициализация ключевого контейнера и получение сертификата и закрытого ключа.
KeyStore keyStore = KeyStore.getInstance(JCP. HD_STORE_NAME);
PrivateKey privateKey = (PrivateKey)keyStore.getKey(ALIAS, PASSWORD);
X509Certificate cert = (X509Certificate)keyStore.getCertificate(ALIAS);
// Подготовка сообщения: в данном случае — это чтение сообщения из файла message.xml в кодировке UTF-8.
MessageFactory mf = MessageFactory.newInstance();
SOAPMessage message = mf.createMessage();
SOAPPart soapPart = message.getSOAPPart();
FileInputStream is = new FileInputStream(“message.xml”);
soapPart.setContent(new StreamSource(is));
message.getSOAPPart().getEnvelope().addNamespaceDeclaration(“ds”, “http://www.w3.org/2000/09/xmldsig#”);
Document doc = message.getSOAPPart().getEnvelope().getOwnerDocument();
Добавляем заголовки для помещения информации о подписи:
WSSecHeader header = new WSSecHeader();
header.setActor(“http://smev.gosuslugi.ru/actors/smev”);
header.setMustUnderstand(false);
header.insertSecurityHeader(message.getSOAPPart().getEnvelope().getOwnerDocument());
// Элемент подписи.
Element token = header.getSecurityHeader();
Далее необходимо создать экземпляр сервис-провайдера для подписи документа:
// Загрузка провайдера.
Provider xmlDSigProvider = new ru. CryptoPro. JCPxml.dsig.internal.dom. XMLDSigRI();
Добавляем описание преобразований над документом и узлом SignedInfo согласно методическим рекомендациям СМЭВ. К каноническому виду приводим с помощью алгоритма http://www.w3.org/2001/10/xml-exc-c14n#:
final Transforms transforms = new Transforms(doc);
transforms.addTransform(Transforms. TRANSFORM_C14N_EXCL_OMIT_COMMENTS);
XMLSignatureFactory fac = XMLSignatureFactory.getInstance(“DOM”, xmlDSigProvider);
Преобразования над узлом :
Добавляем ссылку на подписываемый узел с идентификатором “body”:
// Ссылка на подписываемые данные с алгоритмом хеширования ГОСТ 34.11.
Reference ref = fac.newReference(“#body”, fac.newDigestMethod(“http://www.w3.org/2001/04/xmldsig-more#gostr3411”, null),
transformList, null, null);
Задаём алгоритм подписи:
SignedInfo si = fac.newSignedInfo( fac.newCanonicalizationMethod(CanonicalizationMethod. EXCLUSIVE,
(C14NMethodParameterSpec) null), fac.newSignatureMethod(“http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411”, null), Collections.singletonList(ref));
В качестве алгоритма хэширования был задан алгоритм ГОСТ Р 34.11-94, а алгоритма подписи — ГОСТ Р 34.10-2001.
Создаём узел с информацией о сертификате:
KeyInfoFactory kif = fac.getKeyInfoFactory();
X509Data x509d = kif.newX509Data(Collections.singletonList((X509Certificate) cert));
KeyInfo ki = kif.newKeyInfo(Collections.singletonList(x509d));
Подписываем данные в элементе token:
javax.xml.crypto.dsig. XMLSignature sig = fac.newXMLSignature(si, ki);
DOMSignContext signContext = new DOMSignContext((Key) privateKey, token);
sig.sign(signContext);
Следующий этап — поместить узел и сертификат (X509Certificate) в узел , причём сертификат нужно удалить из и оставить там ссылку на с сертификатом:
Теперь документ готов к отправке.
Семь раз проверь, один — отрежь.
Резать мы конечно ничего не будем, но вот проверить подпись в сообщении из СМЭВ перед его обработкой необходимо. Хотя бы один раз.
Проверка подписи производится следующим образом:
Сертификат в примере извлекается из узла , и его открытый ключ используется для проверки подписи.
В следующей серии мы вернёмся в мир . NET, где вас ждёт пример работы со СМЭВ с использованием WCF.