Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

9 Страницы«<789
Опции
К последнему сообщению К первому непрочитанному
Offline migel  
#161 Оставлено : 6 февраля 2020 г. 13:46:12(UTC)
migel

Статус: Активный участник

Группы: Участники
Зарегистрирован: 30.01.2019(UTC)
Сообщений: 35
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Автор: two_oceans Перейти к цитате
Автор: migel Перейти к цитате
Не подтверждается (модификацией трансформа смыва)
тестовый прогон с collapse поведением - то есть заменой [0x10,0x13]->0x20
и уборкой лидирующих/завершающих пробелов
документ не валидируется
Там еще и замена подряд идущих на один пробел. Мне кажется что может быть проблема с порядком действий, трансформ смэва выполняется после каноникализации, то есть до него тем более 13 не дойдут. Вообще я предполагаю, что смэв валидирует через Джаву с применением КриптоПро, то есть чем гадать все варианты можно как первое приближение посмотреть поведение адаптера на Джаве. Я тоже попробую варианты на тестовой форме смэв 3.


В общем добил Brick wall
Collapse тоже не по канону последовательности WS не схлопываются в один пробел (0x20)
Исходный документ
z1.xml (7kb) загружен 8 раз(а).
результат подписи
signed_z1.xml (9kb) загружен 11 раз(а).

достигается заменой один 0xa на один пробел (и да никаких сверток пробельных символов)
и пропуском символов 0xD вообще

Отредактировано пользователем 6 февраля 2020 г. 14:11:59(UTC)  | Причина: Добавил требование пропуска 0xD

Offline two_oceans  
#162 Оставлено : 6 февраля 2020 г. 14:17:18(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,342
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
Все равно что-то не так. Предположим 10 и 13 в виде ссылки (&#xA; и &#xD;) обрабатываются однаково и заменяются на один пробел, тогда замена одного на другой не изменит хэша и подпись будет верна. Однако если в форме ввести тот же текст, но заменить A на D - ЭЦП становится неверной. Поэтому 13 обрабатывается отлично от 10.

А вот замена A на 9 проходит без последствий. И &#xA; на пробел тоже.

О еще и пропуск 13 добавился. Значит их можно навставлять целую тучу. Забавно. Правда маковские концы строк это вроде как раз 13.

Отредактировано пользователем 6 февраля 2020 г. 14:26:09(UTC)  | Причина: Не указана

Offline migel  
#163 Оставлено : 6 февраля 2020 г. 14:27:20(UTC)
migel

Статус: Активный участник

Группы: Участники
Зарегистрирован: 30.01.2019(UTC)
Сообщений: 35
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Автор: two_oceans Перейти к цитате

О еще и пропуск 13 добавился.

Кристобаль Хозевич успел первым (ц) Dancing

Offline AntonChik  
#164 Оставлено : 19 марта 2020 г. 7:43:27(UTC)
AntonChik

Статус: Новичок

Группы: Участники
Зарегистрирован: 07.08.2019(UTC)
Сообщений: 4
Российская Федерация

Сказал(а) «Спасибо»: 1 раз
Здравствуйте.
Подписываю сообщение SendRequestRequest и оно успешно проходит проверку на https://smev3.gosuslugi.ru/portal/checkxmlform.jsp

ЭП-ОВ подтверждена
ЭЦП подтверждена

Подставляю другой вид сведений и получаю:

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

Т.е. заметьте "ЭЦП подтверждена", но есть проблема с ЭП-ОВ, которая отвечает за весь контверт, в отличии от ЭП-СП, которая отвечает как раз за элемент в видом сведений(!), который был изменен.
Поэтому пока что впал в ступор, куда смотреть.

Обратил внимание, что в проблемном виде сведений нет Id, а есть ИдЗапрос, который код не видит, а потому потом возникает пустой <Reference URI=""> (или так может быть?)
Но в МР написано:
"С помощью ЭП-СП подписывается элемент, находящийся в //MessagePrimaryContent (между открывающим и закрывающим тегами), имеющий атрибут Id"
т.е. речь только про Id

Если же все-таки вместо Id искать ИдЗапрос, то потом возникает ошибка "Неверное сформирована ссылка" и подпись не вычисляется вообще. Стоит ли решать эту проблему или это ошибочная ветка рассуждений? Ведь вообще о проблеме с ЭП-СП не написано, а влияет ли это как-то на ЭП-ОВ непонятно.

Пакеты прикрепил.
Буду рад любым советам и мыслям.
1 EhP-OV podtverzhdena, EhCP podtverzhdena.xml (11kb) загружен 4 раз(а). 2 EhP-OV ne podtverzhdena Oshibka proverki EhP Narushena celostnost' EhP. EhCP podtverzhdena.xml (10kb) загружен 5 раз(а).
Offline two_oceans  
#165 Оставлено : 19 марта 2020 г. 10:16:08(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,342
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
Добрый день!
Ветка, полагаю, верная - удобно, когда все по СМЭВ 3 в одной теме. ЭП-СП находится внутри тега, подписываемого ЭП-ОВ и не удаляется перед подписанием ЭП-ОВ (по крайней мере, если нет трансформа enveloped-signature), поэтому косвенное влияние готовой ЭП-СП на процесс подписания и проверки ЭП-ОВ есть. Важно, что ЭП-СП подписывается раньше ЭП-ОВ. Ошибка может возникать, наоборот, в случае, когда подписали ЭП-ОВ, а потом пытаетесь подписать ЭП-СП (это нарушит ЭП-ОВ).
Файлы посмотрю, отпишу.

UPD. Посмотрел, пока причину не вижу, но у Вас используется трансформ enveloped-signature и хэш sha1. Трансформ имеет разночтения как его применять в случае когда подпись 1 от фрагмента 1 вложена во фрагмент 2, подписываемый подписью 2. Из-за этих разночтений не могу гарантировать, что порекомендую о трансформе правильно, я работаю без трансформа и подпись 1 остается при расчете хэша трансформа 2. Для Signature Algorithm указана схема гост-2012, поэтому для Digest Algorithm нужен тоже хэш гост-2012, а не sha1.

Отредактировано пользователем 19 марта 2020 г. 11:35:33(UTC)  | Причина: Не указана

Offline AntonChik  
#166 Оставлено : 19 марта 2020 г. 14:16:02(UTC)
AntonChik

Статус: Новичок

Группы: Участники
Зарегистрирован: 07.08.2019(UTC)
Сообщений: 4
Российская Федерация

Сказал(а) «Спасибо»: 1 раз
Автор: two_oceans Перейти к цитате
Для Signature Algorithm указана схема гост-2012, поэтому для Digest Algorithm нужен тоже хэш гост-2012, а не sha1.

Спасибо. Это поправил. Теперь
<DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256" />
вместо
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
Но это и не помогло и не помешало (не сломало рабочий вида сведений)

Продолжим.

Была ошибка при расчете подписи "Неверно сформированный элемент reference"
Имеется в виду пустой <Reference URI=""> т.к. GetIdElement не нашел элемент по аттрибуту Id="AC439881-E925-771B-E040-A8C062C84DEE"
Решение приводили однако даже где-то выше в этом топике.
Я унаследовал класс SignedXmlEx от SignedXml и переопределил GetIdElement, чтоб искал по аттрибуту ИдЗапрос="AC439881-E925-771B-E040-A8C062C84DEE"

Код:
        public override XmlElement GetIdElement(XmlDocument doc, string id)
        {
            XmlElement idElem = base.GetIdElement(doc, id);

            if (idElem == null)
            {
                idElem = doc.SelectSingleNode("//*[@ИдЗапрос=\"" + id + "\"]") as XmlElement;
            }
            return idElem;
        }


Теперь URI заполнился <Reference URI="#AC439881-E925-771B-E040-A8C062C84DEE">
Подпись посчиталась.
Но при проверке на https://smev3.gosuslugi.ru/portal/checkxmlform.jsp вот такая беда:

ЭЦП не подтверждена: #AC439881-E925-771B-E040-A8C062C84DEE org.apache.xml.security.signature.MissingResourceFailureException: The Reference for URI #AC439881-E925-771B-E040-A8C062C84DEE has no XMLSignatureInput Original Exception was org.apache.xml.security.signature.ReferenceNotInitializedException: Cannot resolve element with ID AC439881-E925-771B-E040-A8C062C84DEE Original Exception was org.apache.xml.security.signature.ReferenceNotInitializedException: Cannot resolve element with ID AC439881-E925-771B-E040-A8C062C84DEE Original Exception was org.apache.xml.security.signature.ReferenceNotInitializedException: Cannot resolve element with ID AC439881-E925-771B-E040-A8C062C84DEE Original Exception was org.apache.xml.security.utils.resolver.ResourceResolverException: Cannot resolve element with ID AC439881-E925-771B-E040-A8C062C84DEE
ЭЦП подтверждена

Ощущение, что я у себя-то поправил, а они не в курсе)

Суть в том, что в предыдущих решениях проблемы "Неверно сформированный элемент reference" переопределение GetIdElement давало поиск все того же Id (там решались проблемы с неймспейсами)
А про ИдЗапрос или другие альтернативы Id я ничего не нашел. Как-то это старнно. Что дальше делать пока не знаю.
Подписанный запрос прикрепил.

3.xml (10kb) загружен 3 раз(а).


Offline two_oceans  
#167 Оставлено : 20 марта 2020 г. 5:33:16(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,342
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
Автор: AntonChik Перейти к цитате
Спасибо.
Пожалуйста.
Автор: AntonChik Перейти к цитате
Была ошибка при расчете подписи "Неверно сформированный элемент reference"
Имеется в виду пустой <Reference URI=""> т.к. GetIdElement не нашел элемент по аттрибуту Id="AC439881-E925-771B-E040-A8C062C84DEE"
Если URI пустая строка на расчет хэша должен подаваться весь документ, поэтому немного сама по себе проверка должна срабатывать, но возможно не будет расценено как ЭП-ОВ верного фрагмента.
Автор: AntonChik Перейти к цитате
Решение приводили однако даже где-то выше в этом топике.
Я унаследовал класс SignedXmlEx от SignedXml и переопределил GetIdElement, чтоб искал по аттрибуту ИдЗапрос="AC439881-E925-771B-E040-A8C062C84DEE"
...
Ощущение, что я у себя-то поправил, а они не в курсе)
Именно так. Нельзя просто взять с потолка какой-то атрибут и назначить его вместо Id, как минимум у атрибута должен быть тип xs:ID (это надо смотреть в схеме xsd для пространства urn://x-artefacts-fns-inn-singular/root/270-18/4.0.1). Если атрибут ИдЗапрос имеет такой тип, то его можно выбрать вместо Id (тогда это недоработка проверки по стандарту), если тип ИдЗапрос другой то надо добавить атрибут с типом xs:ID, например, тот самый Id из пространства по умолчанию (если пространство имен его разрешает) или wsu:Id (и определение префикса wsu, если разрешены другие пространства имен) либо оставить URI="" и выбрать фрагмент через XPath трансформ (я бы не рекомендовал для СМЭВ, но в сценарии для этого конкретного вида сведений https://smev3.gosuslugi....p;page=1&dTest=false почему именно он, с примерами как выбрать фрагмент по XPath по значению ИдЗапрос).
Автор: AntonChik Перейти к цитате
Суть в том, что в предыдущих решениях проблемы "Неверно сформированный элемент reference" переопределение GetIdElement давало поиск все того же Id (там решались проблемы с неймспейсами)
А про ИдЗапрос или другие альтернативы Id я ничего не нашел. Как-то это старнно. Что дальше делать пока не знаю.
Подписанный запрос прикрепил. 3.xml (10kb) загружен 3 раз(а).
Посмотрю файл, отпишу.

UPD. В первой подписи предсказуемо не находится подписанный фрагмент. Само значение подписи проверяется успешно, то есть хэш SignedInfo, сертификат в порядке.
Во второй подписи у меня срабатывает enveloped-signature и удаляет первую, хэш не сходится. Само значение подписи проверяется успешно, то есть хэш SignedInfo, сертификат в порядке.

К слову, отметил 2 момента: 1) 3.xml не в кодировке UTF-8, перекодировал; 2) у обоих подписей одинаковый Id - нехорошо. Для базовой xmldsig разницы нет (только документ невалидный), но с xades форматами это может вызвать проблемы создания/проверки подписи.

Отредактировано пользователем 20 марта 2020 г. 10:07:09(UTC)  | Причина: Не указана

Offline AntonChik  
#168 Оставлено : 20 марта 2020 г. 6:11:26(UTC)
AntonChik

Статус: Новичок

Группы: Участники
Зарегистрирован: 07.08.2019(UTC)
Сообщений: 4
Российская Федерация

Сказал(а) «Спасибо»: 1 раз
Автор: two_oceans Перейти к цитате
Нельзя просто взять с потолка какой-то атрибут и назначить его вместо Id

Да, затея изначально казалась сомнительной.

Опять же ссылаясь на МР
Цитата:
По требованиям поставщика сведений подпись ЭП-СП может быть обязательной для подписи блока сведений по форматам поставщика.

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

Полностью убрал подпись элемента вида услуг.
Теперь проверка выдает просто:
"ЭЦП подтверждена"

Буду пробовать отправлять запрос в тестовую среду.



Offline just.skorik  
#169 Оставлено : 18 мая 2020 г. 12:15:22(UTC)
just.skorik

Статус: Новичок

Группы: Участники
Зарегистрирован: 24.11.2015(UTC)
Сообщений: 1
Российская Федерация

Коллеги, добрый день.
Имеется вопрос по сертификации CryptoPro .NET SDK компонентов ФСБ.
Правильно ли я понимаю, что (для работы со СМЭВ 3.х) такая сертификация не требуется, так как CryptoPro .NET прадставляет из себя интерфейс к стертифицированному СКЗИ CryptoPro CSP?
Offline Tolmasov  
#170 Оставлено : 3 июля 2020 г. 21:05:22(UTC)
Tolmasov

Статус: Новичок

Группы: Участники
Зарегистрирован: 30.06.2020(UTC)
Сообщений: 2

Здравствуйте, коллеги!

Стоит задача по переводу подписания запросов для СМЭВ3 с ПО Validata на ПО КриптоПро под .Net. Подпись должна осуществляется по алгоритму ГОСТ 34.10-2012

Функционал на валидате рабочий. Валидата не подписывает xml целиком, а отдельно считает хэш по ГОСТ 34.11-2012 и подписывает его по ГОСТ 34.10-2012. Собственно эти части и нужно перевести на криптопро.

Код:

//inputBytes - это уже каноничный и трансформированный вид сообщения
var inputBytes = System.Text.Encoding.UTF8.GetBytes(xmlSignedInfoCanon);

// Создаем объект для хэширования.
HashAlgorithm myhash = HashAlgorithm.Create("GOST3411");

// Вычисляем хэш от всех прочитанных данных. Хэш считается верно и совпадает с решением на валидате.
byte[] hashValue = myhash.ComputeHash(inputBytes);

// Инициализация крипто-провайдера
Gost3410_2012_256CryptoServiceProvider Gost = (Gost3410_2012_256CryptoServiceProvider)MyCertificate.PrivateKey;
// Подписываем хэш
byte[] signedInfoHashData = Gost.SignHash(hashValue);



Сертификат выпущен тестовым УЦ КриптоПро. Скрин сертификата

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

Подозреваю, что что-то не так делаю.. но не пойму куда копать
Online Александр Лавник  
#171 Оставлено : 4 июля 2020 г. 16:43:54(UTC)
Александр Лавник

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 30.06.2016(UTC)
Сообщений: 2,579
Мужчина
Российская Федерация

Сказал «Спасибо»: 44 раз
Поблагодарили: 585 раз в 552 постах
Автор: Tolmasov Перейти к цитате
Здравствуйте, коллеги!

Стоит задача по переводу подписания запросов для СМЭВ3 с ПО Validata на ПО КриптоПро под .Net. Подпись должна осуществляется по алгоритму ГОСТ 34.10-2012

Функционал на валидате рабочий. Валидата не подписывает xml целиком, а отдельно считает хэш по ГОСТ 34.11-2012 и подписывает его по ГОСТ 34.10-2012. Собственно эти части и нужно перевести на криптопро.

Код:

//inputBytes - это уже каноничный и трансформированный вид сообщения
var inputBytes = System.Text.Encoding.UTF8.GetBytes(xmlSignedInfoCanon);

// Создаем объект для хэширования.
HashAlgorithm myhash = HashAlgorithm.Create("GOST3411");

// Вычисляем хэш от всех прочитанных данных. Хэш считается верно и совпадает с решением на валидате.
byte[] hashValue = myhash.ComputeHash(inputBytes);

// Инициализация крипто-провайдера
Gost3410_2012_256CryptoServiceProvider Gost = (Gost3410_2012_256CryptoServiceProvider)MyCertificate.PrivateKey;
// Подписываем хэш
byte[] signedInfoHashData = Gost.SignHash(hashValue);



Сертификат выпущен тестовым УЦ КриптоПро. Скрин сертификата

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

Подозреваю, что что-то не так делаю.. но не пойму куда копать

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

Попробуйте побайтово перевернуть полученную подпись.
Техническую поддержку оказываем тут
Наша база знаний
Offline Tolmasov  
#172 Оставлено : 4 июля 2020 г. 19:47:28(UTC)
Tolmasov

Статус: Новичок

Группы: Участники
Зарегистрирован: 30.06.2020(UTC)
Сообщений: 2

Цитата:
Попробуйте побайтово перевернуть полученную подпись.


Если я правильно понял, то представил байтовый массив в обратном порядке. Не помогло, ошибка та же.
Подпись:
Convert.ToBase64String(signedInfoHashData)
"KPBTk0b86091PMXvpYZpmxy9PVApG3HAx/DpgUZjeOeKdgkeQJgHSGm3U6Y+No763P3NrWHwieF3oxhJTag2kw=="

Перевернул:
Convert.ToBase64String(signedInfoHashDataRevers)
"kzaoTUkYo3fhifBhrc393PqONj6mU7dpSAeYQB4JdorneGNGgenwx8BxGylQPb0cm2mGpe/FPHVP6/xGk1PwKA=="

Причем проверка подписанного хэша проходит проверку успешно.
Перевернутую подпись сам провайдер криптопро считает не верным.
Код:
Gost.VerifySignature(hashValue, signedInfoHashData); //true


Код:
Gost.VerifySignature(hashValue, signedInfoHashDataRevers); //false


Однако если проверяю подпись уже всего подписанного xml
Код:

SignedXml signedXml = new SignedXml(xmlDocument);
signedXml.SafeCanonicalizationMethods.Add("urn://smev-gov-ru/xmldsig/transform");
bool resultsing = signedXml.CheckSignature(); //false




Может портал СМЭВ не валидировать подпись, если подписываю сертификатом выданным тестовым УЦ КриптоПро?

Отредактировано пользователем 4 июля 2020 г. 20:29:02(UTC)  | Причина: Не указана

Offline two_oceans  
#173 Оставлено : 23 июля 2020 г. 2:42:06(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,342
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
Добрый день. Снова пока меня не было никто не объяснил, что делаете не так.
Как я понял, Вы либо использовали алгоритмы не те что указаны в SignedInfo либо алгоритм хэша не соответствует алгоритму подписи. Немного странно, что хэш вычислен "GOST3411" (по гост-94 как для подписи по гост-2001).

Если еще актуально, ну и чтобы не повторяли за Вами, напомню шаги XMLDSIG.
1) сначала Вы считаете хэш от подписываемого каноникализированного и трансформированного фрагмента.
2) из хэша вычисленного в пункте 1 формируете структуру SignedInfo. Каноникализируете ее (но не трансформируете). У меня обычно добавляется 1 объявление пространства имен, остальное как было.
3) вычисляете хэш от SignedInfo. Значение хэша от SignedInfo само нигде не фигурирует в итоговом документе, что делает отладку еще сложнее. Алгоритм хэша здесь должен быть согласован с алгоритмом подписания - если ключ гост-2012, то хэш должен быть гост-2012, хэш гост-94 уже не прокатит.
4) подписываете хэш от SignedInfo. Обратите внимание, что тут нежелательно использовать SignHash, так как у Вас может оказаться 2 объекта хэша с разными алгоритмами, но одной длиной хэша (один внутри экземпляра класса Gost с гост-2012, второй myhash с гост-94). В этом случае Вы не получите ошибку о несоответствии алгоритма, но подпись будет неверна. Поэтому корректнее использовать Sign/SignData от inputBytes.
5) подписанное значение указываете в SignatureValue, при необходимости зеркалите массив байтов (меняете первый байт с последним, второй с предпоследним и т.д.) до Base64 кодирования. Вроде бы .Net уже переворачивает в фоновом режиме, но мало ли.


Если Вы проверяете на тестовой страничке портала СМЭВ 3, то там сертификат без разницы каким УЦ выдан. Проверяется чисто математика.
Если Вы отправляете в СМЭВ 3, то сертификат и УЦ имеют значение, а также они должны быть зарегистрированы к конкретной ИС. Можно запросить сертификат для тестовой/среды разработки СМЭВ 3 у тестового УЦ ростелекома через Ситуационный центр, но и аккредитованный УЦ тоже подойдет. Для продуктивной сертификат должен быть от аккредитованного УЦ.

Отредактировано пользователем 23 июля 2020 г. 3:24:57(UTC)  | Причина: Не указана

Offline Соня Базурова  
#174 Оставлено : 20 октября 2020 г. 19:00:28(UTC)
Соня Базурова

Статус: Новичок

Группы: Участники
Зарегистрирован: 29.12.2014(UTC)
Сообщений: 4
Российская Федерация
Откуда: Москва

Поблагодарили: 1 раз в 1 постах
Нет ли у кого примера xml пакета отправки сертификата ЭЦП в ГИС ГМП 2.1.1 ?
Отправляю такой пакет:

Код:

<?xml version="1.0" encoding="utf-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:basic="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2">
  <S:Body>
    <ns2:SendRequestRequest>
      <ns2:SenderProvidedRequestData Id="SIGNED_BY_CONSUMER">                       
        <ns2:MessageID>61208680-1313-11eb-ba7f-af54ffe1ca92</ns2:MessageID>
        <basic:MessagePrimaryContent>
          <ic:ImportCertificateRequest xmlns:com="http://roskazna.ru/gisgmp/xsd/Common/2.1.1" xmlns:ic="urn://roskazna.ru/gisgmp/xsd/services/import-certificates/2.1.1" Id="G_0EE01C71-9E47-41F1-B991-12E982FA7659" timestamp="2020-10-20T15:32:31.977+05:00" senderIdentifier="0101d1" senderRole="2">
    <ic:RequestEntry Id="I_61677a90-1313-11eb-b55e-e06d040a5d8a" ownership="0101d1"/>
        </ic:ImportCertificateRequest>
        </basic:MessagePrimaryContent>
<basic:AttachmentHeaderList>
                    <basic:AttachmentHeader>
                        <basic:contentId>I_61677a90-1313-11eb-b55e-e06d040a5d8a</basic:contentId>
                        <basic:MimeType>application/x-x509-ca-cert</basic:MimeType>
                        <basic:SignaturePKCS7>MIIUwgY............Здесь base64 подписи PKCS7 сертификата..........PRQ=</basic:SignaturePKCS7>
                    </basic:AttachmentHeader>
                </basic:AttachmentHeaderList>
        <ns2:TestMessage/>
      </ns2:SenderProvidedRequestData>
      <basic:AttachmentContentList>
                <basic:AttachmentContent>
                    <basic:Id>I_61677a90-1313-11eb-b55e-e06d040a5d8a</basic:Id>                    
                    <basic:Content>MIIJKTCCCN..........Здесь сам сертификат в виде base64........3RlT</basic:Content>
                </basic:AttachmentContent>
            </basic:AttachmentContentList>
    </ns2:SendRequestRequest>
  </S:Body>
</S:Envelope>


возвращается ошибка:

Код:

 <ns2:AsyncProcessingStatus>
  <ns2:OriginalMessageId>61208680-1313-11eb-ba7f-af54ffe1ca92</ns2:OriginalMessageId>
  <ns2:StatusCategory>requestIsRejectedBySmev</ns2:StatusCategory>
  <ns2:StatusDetails>Бизнес-данные сообщения не соответствуют схеме, зарегистрированной в СМЭВ. MessageId = 61208680-1313-11eb-ba7f-af54ffe1ca92</ns2:StatusDetails>
- <ns2:SmevFault xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns3:InvalidContent">
  <Code>tsmev3:P:TSMEV3_ASYNC_CORE1:TR:ASYNC:PP:BSV:3</Code>
  <Description>SMEV-403:Бизнес-данные сообщения не соответствуют схеме, зарегистрированной в СМЭВ. MessageId = 61208680-1313-11eb-ba7f-af54ffe1ca92</Description>
  <ns3:ValidationError errorPosition="-1">cvc-id.1: There is no ID/IDREF binding for IDREF 'I_61677a90-1313-11eb-b55e-e06d040a5d8a'.</ns3:ValidationError>
  </ns2:SmevFault>
  </ns2:AsyncProcessingStatus>


Подписываю только ветку SenderProvidedRequestData.
Подписывание ветки ImportCertificateRequest, видимо, необязательное - проверку пакет проходит и с подписью, и без.
За основу xml-пакета взят пакет из темы Проблема с подписью для СМЭВ.
Offline two_oceans  
#175 Оставлено : 21 октября 2020 г. 10:34:34(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,342
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
Вообще на вид сообщение похоже на правду. Правильного вида, к сожалению, нет под рукой - не самый ходовой вид сведений.
Судя по детальному описанию в конце ошибки
Код:
There is no ID/IDREF binding for IDREF 'I_61677a90-1313-11eb-b55e-e06d040a5d8a'
валидатор СМЭВ не смог связать два ID.

Отредактировано пользователем 21 октября 2020 г. 10:55:33(UTC)  | Причина: Не указана

Offline Соня Базурова  
#176 Оставлено : 21 октября 2020 г. 16:52:43(UTC)
Соня Базурова

Статус: Новичок

Группы: Участники
Зарегистрирован: 29.12.2014(UTC)
Сообщений: 4
Российская Федерация
Откуда: Москва

Поблагодарили: 1 раз в 1 постах
По тестовому сценарию получается, что ImportCertificateRequest/RequestEntry/@Id должен быть равен 'I_6e188de4-8491-49ea-8ec6-a09a607d020a'.

По схеме Common.xsd, получается, что RequestEntry/@Id (type="xsd:IDREF") - это "уникальный в пределах запроса идентификатор описания сертификата используемый для поиска самого сертификата в элементе basic:AttachmentContentList запроса СМЭВ".

По схеме smev-message-exchange-basic-1.xsd указано, что элемент AttachmentHeaderList/AttachmentHeader/contentId - идентификатор вложения. Ссылка на соответствующий //AttachmentContent/@Id.

Заполняю эти три идентификатора одинаковым значением I_6e188de4-8491-49ea-8ec6-a09a607d020a, но ошибка всё та же:
cvc-id.1: There is no ID/IDREF binding for IDREF 'I_6e188de4-8491-49ea-8ec6-a09a607d020a'.

Не понимаю, с какой ссылкой должно быть ещё совпадение :(((

Прикреплю файл smev-message-exchange-basic-1.xsd
smev-message-exchange-basic-1.zip (4kb) загружен 1 раз(а).
Offline two_oceans  
#177 Оставлено : 24 октября 2020 г. 13:19:21(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,342
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
Лично меня смущает что там "//AttachmentContent/@Id", так как собаку ставят перед именем атрибута, но Id в схеме это element (то есть, тег?). Но тогда извлечение должно быть вроде такого "//AttachmentContent/Id/textnode()". Про RequestEntry/@Id вопросов нет, там именно атрибут. Выходит какая-то ерунда: в AttachmentContent должен быть еще и атрибут Id.

Отредактировано пользователем 24 октября 2020 г. 13:22:34(UTC)  | Причина: Не указана

Offline vyacheslav123456789  
#178 Оставлено : 15 января 2021 г. 1:04:38(UTC)
vyacheslav123456789

Статус: Новичок

Группы: Участники
Зарегистрирован: 14.01.2021(UTC)
Сообщений: 1
Российская Федерация

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

<smev:GetRequestRequest xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:smevbasic="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.2" xmlns:faults="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.2" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:smev="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.2">
<smevbasic:MessageTypeSelector Id="SIGNED_BY_CONSUMER">
<smevbasic:Timestamp>2021-01-15T00:07:06.9541401+04:00</smevbasic:Timestamp>
</smevbasic:MessageTypeSelector>
<smev:CallerInformationSystemSignature>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256" />
<Reference URI="#SIGNED_BY_CONSUMER">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<Transform Algorithm="urn://smev-gov-ru/xmldsig/transform" />
</Transforms>
<DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256" />
<DigestValue>Nq3ZumwSn8VJvbN2dC0eSnzytbje/2NhQnfoOtOStE8=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>qUBhKRML951sSKO/W6vpaMLQ35x46HeKwF14pRH26D9xmL6earCG+EhacSZcK9qUpKmXOtUBBdP2kI+fVjCzYw==</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIIJHzCCCMqgAwIBAgIQAdaCrmGNKhAAAADEAAYAAjAMBggqhQMHAQEDAgUAMIIBmzEYMBYGA1UEAwwP0J7QkNCeICLQmNCY0KIiMXAwbgYDVQQKDGfQntGC0LrRgNGL0YLQvtC1INCQ0LrRhtC40L7QvdC10YDQvdC+0LUg0J7QsdGJ0LXRgdGC0LLQviAi0JjQvdGE0L7QotC10JrQoSDQmNC90YLQtdGA0L3QtdGCINCi0YDQsNGB0YIiMQswCQYDVQQGEwJSVTEcMBoGA1UECAwTNzcg0LMuINCc0L7RgdC60LLQsDEVMBMGA1UEBwwM0JzQvtGB0LrQstCwMSUwIwYJKoZIhvcNAQkBFhZTdXBwb3J0SUlUQGluZm90ZWNzLnJ1MW4wbAYDVQQJDGXQodGC0LDRgNGL0Lkg0J/QtdGC0YDQvtCy0YHQutC+LdCg0LDQt9GD0LzQvtCy0YHQutC40Lkg0L/RgNC+0LXQt9C0LCDQtC4gMS8yMywg0YHRgtGALiAxLCDQvtGE0LjRgSA4ODEaMBgGCCqFAwOBAwEBEgwwMDc3NDMwMjA1NjAxGDAWBgUqhQNkARINMTAyNzczOTExMzA0OTAeFw0yMDA5MDQxMTI3MzFaFw0yMTA5MDQxMTI3MzFaMIIBPjEmMCQGA1UEAwwd0JzQmNCd0JfQlNCg0JDQkiDQoNCe0KHQodCY0JgxJjAkBgNVBAoMHdCc0JjQndCX0JTQoNCQ0JIg0KDQntCh0KHQmNCYMQowCAYDVQQLDAEwMQswCQYDVQQGEwJSVTEcMBoGA1UECAwTNzcg0LMuINCc0L7RgdC60LLQsDEVMBMGA1UEBwwM0JzQvtGB0LrQstCwMSAwHgYJKoZIhvcNAQkBFhFjYUByb3NtaW56ZHJhdi5ydTFGMEQGA1UECQw90J/QtdGA0LXRg9C70L7QuiDQoNCw0YXQvNCw0L3QvtCy0YHQutC40LksINC0LiAzLzI1LCDQodCi0KAgMTEaMBgGCCqFAwOBAwEBEgwwMDc3MDc3NzgyNDYxGDAWBgUqhQNkARINMTEyNzc0NjQ2MDg5NjBmMB8GCCqFAwcBAQEBMBMGByqFAwICJAAGCCqFAwcBAQICA0MABEAlgLn3zlvHOeEEENb249rkrDFMHgJuMHcqEyIFQ4ufUbBltA+lIIv6xHYcoWuxQaGTjqkFvsSgiNjenr8oZHECgQkAMDAwNjAwMDKjggUtMIIFKTAOBgNVHQ8BAf8EBAMCA/gwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMEBggqhQMDBQoDATAdBgNVHQ4EFgQUTgrMweTyd/nn+cMOYuD5OtJ408IwJwYDVR0gBCAwHjAIBgYqhQNkcQEwCAYGKoUDZHECMAgGBiqFA2RxAzA0BgUqhQNkbwQrDCki0JrRgNC40L/RgtC+0J/RgNC+IENTUCIg0LLQtdGA0YHQuNGPIDQuMDAMBgNVHRMBAf8EAjAAMIIBzwYFKoUDZHAEggHEMIIBwAyBiNCh0YDQtdC00YHRgtCy0L4g0LrRgNC40L/RgtC+0LPRgNCw0YTQuNGH0LXRgdC60L7QuSDQt9Cw0YnQuNGC0Ysg0LjQvdGE0L7RgNC80LDRhtC40LggKNCh0JrQl9CYKSBWaVBOZXQgQ1NQIDQuMiAo0LjRgdC/0L7Qu9C90LXQvdC40LUgMykMbdCf0YDQvtCz0YDQsNC80LzQvdGL0Lkg0LrQvtC80L/Qu9C10LrRgSAiVmlQTmV0INCj0LTQvtGB0YLQvtCy0LXRgNGP0Y7RidC40Lkg0YbQtdC90YLRgCA0ICjQstC10YDRgdC40Y8gNC42KSIMXtCh0LXRgNGC0LjRhNC40LrQsNGCINGB0L7QvtGC0LLQtdGC0YHRgtCy0LjRjyDihJYg0KHQpC8xMjQtMzQzMyDQvtGCIDA2INC40Y7Qu9GPIDIwMTgg0LPQvtC00LAMZNCh0LXRgNGC0LjRhNC40LrQsNGCINGB0L7QvtGC0LLQtdGC0YHRgtCy0LjRjyDihJYg0KHQpC8xMTgtMzUxMCDQvtGCIDI1INC+0LrRgtGP0LHRgNGPIDIwMTgg0LPQvtC00LAwgbYGCCsGAQUFBwEBBIGpMIGmMC0GCCsGAQUFBzABhiFodHRwOi8vY2FkZXMuaWl0cnVzdC5ydTo4Nzc3L29jc3AwOQYIKwYBBQUHMAKGLWh0dHA6Ly91YzEuaWl0cnVzdC5ydS91Yy9DQS1JSVQtKEszKS0yMDIwLmNlcjA6BggrBgEFBQcwAoYuaHR0cHM6Ly91YzEuaWl0cnVzdC5ydS91Yy9DQS1JSVQtKEszKS0yMDIwLmNlcjBzBgNVHR8EbDBqMDOgMaAvhi1odHRwOi8vdWMxLmlpdHJ1c3QucnUvdWMvQ0EtSUlULShLMyktMjAyMC5jcmwwM6AxoC+GLWh0dHA6Ly91YzIuaWl0cnVzdC5ydS91Yy9DQS1JSVQtKEszKS0yMDIwLmNybDCCAV8GA1UdIwSCAVYwggFSgBQUjJy0itpFeAWQ6iOiHvpKiNvwqqGCASykggEoMIIBJDEeMBwGCSqGSIb3DQEJARYPZGl0QG1pbnN2eWF6LnJ1MQswCQYDVQQGEwJSVTEYMBYGA1UECAwPNzcg0JzQvtGB0LrQstCwMRkwFwYDVQQHDBDQsy4g0JzQvtGB0LrQstCwMS4wLAYDVQQJDCXRg9C70LjRhtCwINCi0LLQtdGA0YHQutCw0Y8sINC00L7QvCA3MSwwKgYDVQQKDCPQnNC40L3QutC+0LzRgdCy0Y/Qt9GMINCg0L7RgdGB0LjQuDEYMBYGBSqFA2QBEg0xMDQ3NzAyMDI2NzAxMRowGAYIKoUDA4EDAQESDDAwNzcxMDQ3NDM3NTEsMCoGA1UEAwwj0JzQuNC90LrQvtC80YHQstGP0LfRjCDQoNC+0YHRgdC40LiCChfwveQAAAAAA7cwDAYIKoUDBwEBAwIFAANBAG/pCjZjJEquHx1MxUSZHtKHXAKXgNE3NbTUIy6AB5L6Q2UoWQlrt5u1ZzfcVbnZsu3YRhM715zhjiWJYbpiEjo=</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
</smev:CallerInformationSystemSignature>
</smev:GetRequestRequest>


При попытке отправить в СМЭВ получаю ошибку:
Data at the root level is invalid. Line 2, position 1.
Не могу понять в чем дело, подскажите пожалуйста хотя бы куда копать

Код подписи, метод CheckSignature() возвращает true

var certificate = GetCertificate(certificateSerial);

var smevSignedXml = new SmevSignedXml(xmlDocument)
{
SigningKey = certificate.PrivateKey,
KeyInfo = new KeyInfo()
};

smevSignedXml.KeyInfo.AddClause(new KeyInfoX509Data(certificate));

Reference reference = new Reference
{
Uri = $"#{id}",
DigestMethod = CPSignedXml.XmlDsigGost3411_2012_256Url
};

reference.AddTransform(new XmlDsigExcC14NTransform());
reference.AddTransform(new XmlDsigSmevTransform());
smevSignedXml.SafeCanonicalizationMethods.Add("urn://smev-gov-ru/xmldsig/transform");
smevSignedXml.AddReference(reference);

smevSignedXml.SignedInfo.CanonicalizationMethod = SignedXml.XmlDsigExcC14NTransformUrl;
smevSignedXml.SignedInfo.SignatureMethod = CPSignedXml.XmlDsigGost3410_2012_256Url;

smevSignedXml.ComputeSignature();

var signatureXml = smevSignedXml.GetXml();

var binaryData = new XmlDocument();

var keyInfo = binaryData.CreateElement("KeyInfo", "http://www.w3.org/2000/09/xmldsig#");

var X509Data = binaryData.CreateElement("X509Data", "http://www.w3.org/2000/09/xmldsig#");
var X509Certificate = binaryData.CreateElement("ds:X509Certificate", "http://www.w3.org/2000/09/xmldsig#");
X509Certificate.InnerText = Convert.ToBase64String(certificate.RawData);

X509Data.AppendChild(X509Certificate);

keyInfo.AppendChild(X509Data);

signatureXml.InnerXml += binaryData.OuterXml;

var signature = binaryData.CreateElement("Signature", "http://www.w3.org/2000/09/xmldsig#");

signature.InnerXml = signatureXml.InnerXml;

var isValid = smevSignedXml.CheckSignature();

return signature;

Буду очень признателен за любую помощь, времени к сожалению, совсем мало
Offline two_oceans  
#179 Оставлено : 26 января 2021 г. 7:57:16(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,342
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
Добрый день.
Если еще нужно - я первый раз зашел в новом году. С подписью проблем не вижу - проверяется корректно. В коде махинации не особо понятны, но выходит верно.

Если отправляете именно то, что выделено желтым и ничего более прямо в СМЭВ, то проблема проста: нет контейнера SOAP, парсер ругается на то что корневой тег не Soap:Envelope. Выделенный желтым текст должен быть внутри Soap:Envelope / Soap:Body, а Soap:Envelope / Soap:Header оставить пустым. В норме MessageTypeSelector уходит на адаптер СМЭВ, который делает обертки smev:GetRequestRequest и Soap:Envelope / Soap:Body, подписывает MessageTypeSelector и отправляет все в СМЭВ 3. Однако раз часть GetRequestRequest обернули сами и подписываете сами, то надо и самую внешнюю обертку Soap добавить.

Отредактировано пользователем 26 января 2021 г. 8:01:33(UTC)  | Причина: Не указана

Offline two_oceans  
#180 Оставлено : 26 января 2021 г. 7:59:01(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,342
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 90 раз
Поблагодарили: 313 раз в 295 постах
del
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
9 Страницы«<789
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.