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

Уведомление

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) загружен 5 раз(а).
результат подписи
signed_z1.xml (9kb) загружен 8 раз(а).

достигается заменой один 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,064
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 69 раз
Поблагодарили: 242 раз в 227 постах
Все равно что-то не так. Предположим 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) загружен 3 раз(а). 2 EhP-OV ne podtverzhdena Oshibka proverki EhP Narushena celostnost' EhP. EhCP podtverzhdena.xml (10kb) загружен 2 раз(а).
Offline two_oceans  
#165 Оставлено : 19 марта 2020 г. 10:16:08(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 69 раз
Поблагодарили: 242 раз в 227 постах
Добрый день!
Ветка, полагаю, верная - удобно, когда все по СМЭВ 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,064
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 69 раз
Поблагодарили: 242 раз в 227 постах
Автор: 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 Ошибка проверки ЭП: Нарушена целостность ЭП"

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

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

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

Сказал «Спасибо»: 33 раз
Поблагодарили: 493 раз в 470 постах
Автор: 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,064
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 69 раз
Поблагодарили: 242 раз в 227 постах
Добрый день. Снова пока меня не было никто не объяснил, что делаете не так.
Как я понял, Вы либо использовали алгоритмы не те что указаны в 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,064
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 69 раз
Поблагодарили: 242 раз в 227 постах
Вообще на вид сообщение похоже на правду. Правильного вида, к сожалению, нет под рукой - не самый ходовой вид сведений.
Судя по детальному описанию в конце ошибки
Код:
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) загружен 0 раз(а).
Offline two_oceans  
#177 Оставлено : 24 октября 2020 г. 13:19:21(UTC)
two_oceans

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

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

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

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

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