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

Уведомление

Icon
Error
2 Страницы<12
Вопрос Подпись SOAP запроса для ГИИС - Не пойму как вычисляется DigestValue и SignatureValue?
Опции
К последнему сообщению К первому непрочитанному
Предыдущая тема Следующая тема
Offline Infopol  
#11 Оставлено : 12 апреля 2022 г. 7:37:22(UTC)
Infopol

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

Группы: Участники
Зарегистрирован: 21.03.2022(UTC)
Сообщений: 33
Откуда: Краснодарский край

Сказал(а) «Спасибо»: 17 раз
Вот пример полученного XML файла
Код:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header></soapenv:Header><soapenv:Body><ns:SendGetBatchRequest xmlns:ns="urn://xsd.dmdk.goznak.ru/exchange/1.0">
<ns:CallerSignature><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:CanonicalizationMethod><ds:SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256"></ds:SignatureMethod>
<ds:Reference URI="#body"><ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"></ds:DigestMethod><ds:DigestValue>L0RCNTNjOGlKTGNJenl0L1ArVVM1NkRiM2JocW1CWEx1akQ0M3h3dmt0WT0=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>ROwYAAAAAAGM7BgAb8fnBYjsGAAc9RgA5O0YAIfH5wWM7BgAHEfrBYg2PhD84zwQeKznBQAAAAC47BgAdT7PdhxH6wWcT3MQNLb3Dv//AAAc9RgA/OwYANzjPBBMfmIErOwYAEjtGADvPM92TEfrBawAAAAEAAAACgAAAAUAAADE5DwQnOQ8EIg2PhAUYr4AAAAAACgwPhAEAAAA6Me8AMjwGAAgAAAAAAAAAAAAAAAAAAAAAAAAANB3HHUQAAAAkO0YAAEAAAS
.............................................
.............................................
2kApkwU8ofe58R4q1lCkyKO0kZJjEgZrEh+vlBzItRRZPwwHJWcZuBhuCLM8KLVKwSO1bDfFf8876r1Nz0jXw==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature></ns:CallerSignature>
<ns:RequestData id="body"><ns:UIN_INP>1111111111111111</ns:UIN_INP></ns:RequestData></ns:SendGetBatchRequest>
</soapenv:Body></soapenv:Envelope>

Отредактировано пользователем 12 апреля 2022 г. 7:38:24(UTC)  | Причина: Не указана
Вверх
Offline two_oceans  
#12 Оставлено : 13 апреля 2022 г. 8:04:50(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 394 раз в 366 постах
Автор: Infopol Перейти к цитате
Привел SignedData к нужному виду
Далее в программе
Цитата:
CADESCOM_CONTENT_ENCODING_TYPE=0 //DBASE64
HashData.Algorithm= CADESCOM_HASH_ALGORITHM(CADESCOM_HASH_METOD) //101
HashData.DataEncoding= CADESCOM_CONTENT_ENCODING_TYPE
hashSignInfo=( CadesComHash(SignInfo,CADESCOM_HASH_METOD))
HashData.Hash(EnCode64Str(SignInfo))
...
ОТЛАДКА(HashData.Value,EnCode64Str(HashData.Value))
Xml.sol(239/1310:9) 6E166A15ACAC3E6FDD22DDA97CD028BE8F5EF3F1B16E406DD5B85E63927C5210, NkUxNjZBMTVBQ0FDM0U2RkREMjJEREE5N0NEMDI4QkU4RjVFRjNGMUIxNkU0MDZERDVCODVFNjM5MjdDNTIxMA==
ОТЛАДКА( ДЛИНА(rawstr),rawstr ) // Длина 128
Xml.sol(240/1311:10) 128, 7119BFFAE59969E6C86C42052...
Сделал все как вы рекомендовали...верификация файла - НЕТ
Выглядит уже лучше. Коллега, в коде похоже не учтена особенность возвращаемого значения из HashData.Value и RAW.SignHash, которая должна быть описана в справке - данные хэша и "чистой" подписи возвращаются в шестнадцатиричном виде, их надо декодировать перед дальнейшими преобразованиями (переворачиванием или кодированием в BASE64). Для хэша нужно декодировать когда формируете Reference. Это прекрасно видно на отладке - в шестнадцатиричный вид при отладке не переводили, а выдана строка в шестнадцатиричном виде. Из-за этого длина будет в 2 раза больше и значение совсем не то, что ожидает функция проверки. Определить это функция проверки хэша не сможет, так как теоретически шестнадцатиричный вид допустимое значение, просто длина больше. Следовательно функция проверки хэша просто выдаст отказ без дополнительной диагностики.

Входная кодировка похоже указана неверно, при кодировании BASE64 указывается 1, а в коде 0:
https://docs.cryptopro.r...om_content_encoding_type
CADESCOM_BASE64_TO_BINARY Кодировка BASE64. 0x01
CADESCOM_STRING_TO_UCS2LE Кодировка UTF-8 или UNICODE. 0x00
Алгоритм под вопросом - 101 закомментировано.
CADESCOM_HASH_ALGORITHM_CP_GOST_3411_2012_256 Алгоритм ГОСТ Р 34.11-2012. 101

В SignedInfo опять где-то потерялись пары слешей и всплыли переводы строк. Длина 582 байта.
Если вернуть слеши, убрать переводы строк, то:
Код:
<ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod><ds:SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256"></ds:SignatureMethod><ds:Reference URI="#body"><ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"></ds:DigestMethod><ds:DigestValue>MjE1QjEzRjc1QzJGQUE2QzFDNzk0NzdGNUMxQ0E5NDIxOTdDRURFMTRGNTIxOTc4QUQwQUFEQjIxNEVEMkEyNA==</ds:DigestValue></ds:Reference></ds:SignedInfo>

7A19D271187FDF572E0906EE2325A923C17462D587701FF41DB09D327C2E8A31
ehnScRh/31cuCQbuIyWpI8F0YtWHcB/0HbCdMnwuijE=
FLIP RESULT:
318A2E7C329DB01DF41F7087D56274C123A92523EE06092E57DF7F1871D2197A
MYoufDKdsB30H3CH1WJ0wSOpJSPuBgkuV99/GHHSGXo=

Подручными средствами можно вычислить хэш командой (имя_файла укажите свое)
Код:
"C:\Program Files (x86)\Crypto Pro\CSP\cpverify.exe" -mk -alg GR3411_2012_256 имя_файла -inverted_halfbytes 0
Цитата:
SignatureSection=CreateSignatureSection(hash,УБР_ПРОБ( rawstr),X509Cert,ДА)
SignatureSection=XML_SirCanocalizireString(SignatureSection)
Text= InsertSignature(Text,SignatureSection,"")
Замечание. Если внешние библиотеки вдруг используют каноникализацию .Net, то версия .Net имеет значение - верная работа будет примерно с версии 4.5 включительно до версии 4.7.2 включительно. На меньших версиях работает неверно для некоторых документов, на более новых версиях неизвестно как работает.

Что происходит в этом месте кода мне не совсем понятно. Зачем еще что-то создается и тем более каноникализируется - в том смысле, что не вижу чтобы туда передавалась переменная SignInfo, которую подписали и которая уже должна быть в каноничном виде. Без передачи той самой SignInfo нет никакой гарантии прохождения проверки подписи.

В том смысле, что если следовать совсем уж точно алгоритму из стандарта, то сначала создается каркас ds:Signature в самом документе (ds:SignedInfo (ds:CanonicalizationMethod, ds:SignatureMethod), пустой тег ds:SignatureValue, пустой ds:KeyInfo), потом они заполняются значениями (ds:SignatureMethod должен согласовываться с сертификатом), добавляются один или несколько ds:Reference. К ds:Reference указываются атрибут URI (по необходимости Type и ID), добавляется ds:Transforms, все действия с фрагментом отражаются трансформами, добавляется ds:DigestMethod, считается хэш по ds:DigestMethod в ds:DigestValue. После добавления и заполнения всех ds:Reference запрещается изменение ds:SignedInfo в документе, но делается копия для каноничного вида ds:SignedInfo. Все изменения (исключения переносов строк и тд) ds:SignedInfo в документе нужно делать до момента взятия копии.
Далее делается каноникализация копии SignedInfo, вычисляется хэш от каноничной копии SignedInfo (алгоритм хэша из ds:SignatureMethod), хэш подписывается в RAW подпись, полученное значение вставляется в SignatureValue.

В примере XML оторван посередине ds:SignedInfo, нет всего промежуточного между тегами SignatureValue и X509Certificate. Для полной проверки желательно прикрепить весь файл без сокращений. Без сертификата не получится проверить SignatureValue. Если не хотите светить рабочий сертификат на форуме, но подойдет и тестовый.

Отредактировано пользователем 13 апреля 2022 г. 8:09:50(UTC)  | Причина: Не указана
Вверх
thanks 1 пользователь поблагодарил two_oceans за этот пост.
Infopol оставлено 13.04.2022(UTC)
Offline Infopol  
#13 Оставлено : 13 апреля 2022 г. 8:21:15(UTC)
Infopol

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

Группы: Участники
Зарегистрирован: 21.03.2022(UTC)
Сообщений: 33
Откуда: Краснодарский край

Сказал(а) «Спасибо»: 17 раз
Спасибо большое.Сегодня займусь переделкой в программе.Надеюсь получится.
Насчет потерянных "//" они есть,просто в программе "Инфо-Предприятие" их в ОТЛАДКА не видно...Перевод строк тоже в виду переноса строки сообщение в форуме.
Вот так создает подписанный XML GostCryptografy и файл проходит проверку.
Код:
<soapenv:Envelope xmlns:ns="urn://xsd.dmdk.goznak.ru/exchange/1.0" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header></soapenv:Header><soapenv:Body><ns:SendGetBatchRequest><ns:CallerSignature><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="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256" /><ds:Reference URI="#body"><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="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256" /><ds:DigestValue>NIK1I+ye3E9Vt/qgvSM7cISNN1UAvfs5YvY3sWc6kUU=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>+ikYx7Lv3cFrPkBO/iZXhnaKbJf+6IYmL52F+mR0D4hcW+tw6eigcxHJ9J+3NChiaosTenfkdL/w7nvrg/iE1Q==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIII............................................................/TCCCKqgAwIBAgIQWZChAJCtx65PKR5ey5PA9DAKBggqhQMHAQEDAjCCAVUxGjAYBgkqhkiG9w0BCQEWC3VjQG5hbG9nLnJ1MRgwFgYFKoUDZAESDTEwNDc3MDcwMzA1MTMxGjAYBggqhQMDgQMBARIMMwU8ofe58R4q1lCkyKO0kZJjEgZrEh+vlBzItRRZPwwHJWcZuBhuCLM8KLVKwSO1bDfFf8876r1Nz0jXw==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><!--You may enter ANY elements at this point--></ns:CallerSignature><ns:RequestData id="body"><ns:UIN_INP>1111111111111111</ns:UIN_INP></ns:RequestData></ns:SendGetBatchRequest></soapenv:Body></soapenv:Envelope>

Самостоятельно у меня всеравно не получается.В секцию SignatureValue вставлял и результат DBASE64 от RawSignature и инвертированое значение и
Hash от SignInfo
Пробовал всякие варианты.
Код:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header></soapenv:Header><soapenv:Body><ns:SendGetBatchRequest xmlns:ns="urn://xsd.dmdk.goznak.ru/exchange/1.0"><ns:CallerSignature><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:CanonicalizationMethod><ds:SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256"></ds:SignatureMethod><ds:Reference URI="#body"><ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"></ds:DigestMethod><ds:DigestValue>MjE1QjEzRjc1QzJGQUE2QzFDNzk0NzdGNUMxQ0E5NDIxOTdDRURFMTRGNTIxOTc4QUQwQUFEQjIxNEVEMkEyNA==</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>MTE1RDAyODJFQkU2NTZDODgxNzQzNzc5RTAyMTc1MUU1NDlGMDJGRTMxNUZEQURBMzc3RTQ0Rjc3MjM2RUYyMUFFMzlEN0MzQjRFMTQxMkMxRkQ1RTY4NkUyN0E3NkNCQUFBMTEyM0JENTZCNUQ1QTdBMEJDRDIzNDVCOEJBMTI=</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIII/TCCCKqgAwIBAgIQWZChAJCtx65PKR5ey5PA9DAKBggqhQMHAQEDAjCCAVUx
...............................................................
kyKO0kZJjEgZrEh+vlBzItRRZPwwHJWcZuBhuCLM8KLVKwSO1bDfFf8876r1Nz0j
Xw==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature></ns:CallerSignature><ns:RequestData id="body"><ns:UIN_INP>1111111111111111</ns:UIN_INP></ns:RequestData></ns:SendGetBatchRequest></soapenv:Body></soapenv:Envelope>

Отредактировано пользователем 13 апреля 2022 г. 10:11:15(UTC)  | Причина: Не указана
Вверх
Offline Infopol  
#14 Оставлено : 13 марта 2023 г. 12:31:14(UTC)
Infopol

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

Группы: Участники
Зарегистрирован: 21.03.2022(UTC)
Сообщений: 33
Откуда: Краснодарский край

Сказал(а) «Спасибо»: 17 раз
Автор: two_oceans Перейти к цитате
Автор: Infopol Перейти к цитате
Привел SignedData к нужному виду
Далее в программе
Цитата:
CADESCOM_CONTENT_ENCODING_TYPE=0 //DBASE64
HashData.Algorithm= CADESCOM_HASH_ALGORITHM(CADESCOM_HASH_METOD) //101
HashData.DataEncoding= CADESCOM_CONTENT_ENCODING_TYPE
hashSignInfo=( CadesComHash(SignInfo,CADESCOM_HASH_METOD))
HashData.Hash(EnCode64Str(SignInfo))
...
ОТЛАДКА(HashData.Value,EnCode64Str(HashData.Value))
Xml.sol(239/1310:9) 6E166A15ACAC3E6FDD22DDA97CD028BE8F5EF3F1B16E406DD5B85E63927C5210, NkUxNjZBMTVBQ0FDM0U2RkREMjJEREE5N0NEMDI4QkU4RjVFRjNGMUIxNkU0MDZERDVCODVFNjM5MjdDNTIxMA==
ОТЛАДКА( ДЛИНА(rawstr),rawstr ) // Длина 128
Xml.sol(240/1311:10) 128, 7119BFFAE59969E6C86C42052...
Сделал все как вы рекомендовали...верификация файла - НЕТ
Выглядит уже лучше. Коллега, в коде похоже не учтена особенность возвращаемого значения из HashData.Value и RAW.SignHash, которая должна быть описана в справке - данные хэша и "чистой" подписи возвращаются в шестнадцатиричном виде, их надо декодировать перед дальнейшими преобразованиями (переворачиванием или кодированием в BASE64). Для хэша нужно декодировать когда формируете Reference. Это прекрасно видно на отладке - в шестнадцатиричный вид при отладке не переводили, а выдана строка в шестнадцатиричном виде. Из-за этого длина будет в 2 раза больше и значение совсем не то, что ожидает функция проверки. Определить это функция проверки хэша не сможет, так как теоретически шестнадцатиричный вид допустимое значение, просто длина больше. Следовательно функция проверки хэша просто выдаст отказ без дополнительной диагностики.

Входная кодировка похоже указана неверно, при кодировании BASE64 указывается 1, а в коде 0:
https://docs.cryptopro.r...om_content_encoding_type
CADESCOM_BASE64_TO_BINARY Кодировка BASE64. 0x01
CADESCOM_STRING_TO_UCS2LE Кодировка UTF-8 или UNICODE. 0x00
Алгоритм под вопросом - 101 закомментировано.
CADESCOM_HASH_ALGORITHM_CP_GOST_3411_2012_256 Алгоритм ГОСТ Р 34.11-2012. 101

В SignedInfo опять где-то потерялись пары слешей и всплыли переводы строк. Длина 582 байта.
Если вернуть слеши, убрать переводы строк, то:
Код:
<ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:CanonicalizationMethod><ds:SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256"></ds:SignatureMethod><ds:Reference URI="#body"><ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"></ds:DigestMethod><ds:DigestValue>MjE1QjEzRjc1QzJGQUE2QzFDNzk0NzdGNUMxQ0E5NDIxOTdDRURFMTRGNTIxOTc4QUQwQUFEQjIxNEVEMkEyNA==</ds:DigestValue></ds:Reference></ds:SignedInfo>

7A19D271187FDF572E0906EE2325A923C17462D587701FF41DB09D327C2E8A31
ehnScRh/31cuCQbuIyWpI8F0YtWHcB/0HbCdMnwuijE=
FLIP RESULT:
318A2E7C329DB01DF41F7087D56274C123A92523EE06092E57DF7F1871D2197A
MYoufDKdsB30H3CH1WJ0wSOpJSPuBgkuV99/GHHSGXo=

Подручными средствами можно вычислить хэш командой (имя_файла укажите свое)
Код:
"C:\Program Files (x86)\Crypto Pro\CSP\cpverify.exe" -mk -alg GR3411_2012_256 имя_файла -inverted_halfbytes 0
Цитата:
SignatureSection=CreateSignatureSection(hash,УБР_ПРОБ( rawstr),X509Cert,ДА)
SignatureSection=XML_SirCanocalizireString(SignatureSection)
Text= InsertSignature(Text,SignatureSection,"")
Замечание. Если внешние библиотеки вдруг используют каноникализацию .Net, то версия .Net имеет значение - верная работа будет примерно с версии 4.5 включительно до версии 4.7.2 включительно. На меньших версиях работает неверно для некоторых документов, на более новых версиях неизвестно как работает.

Что происходит в этом месте кода мне не совсем понятно. Зачем еще что-то создается и тем более каноникализируется - в том смысле, что не вижу чтобы туда передавалась переменная SignInfo, которую подписали и которая уже должна быть в каноничном виде. Без передачи той самой SignInfo нет никакой гарантии прохождения проверки подписи.

В том смысле, что если следовать совсем уж точно алгоритму из стандарта, то сначала создается каркас ds:Signature в самом документе (ds:SignedInfo (ds:CanonicalizationMethod, ds:SignatureMethod), пустой тег ds:SignatureValue, пустой ds:KeyInfo), потом они заполняются значениями (ds:SignatureMethod должен согласовываться с сертификатом), добавляются один или несколько ds:Reference. К ds:Reference указываются атрибут URI (по необходимости Type и ID), добавляется ds:Transforms, все действия с фрагментом отражаются трансформами, добавляется ds:DigestMethod, считается хэш по ds:DigestMethod в ds:DigestValue. После добавления и заполнения всех ds:Reference запрещается изменение ds:SignedInfo в документе, но делается копия для каноничного вида ds:SignedInfo. Все изменения (исключения переносов строк и тд) ds:SignedInfo в документе нужно делать до момента взятия копии.
Далее делается каноникализация копии SignedInfo, вычисляется хэш от каноничной копии SignedInfo (алгоритм хэша из ds:SignatureMethod), хэш подписывается в RAW подпись, полученное значение вставляется в SignatureValue.

В примере XML оторван посередине ds:SignedInfo, нет всего промежуточного между тегами SignatureValue и X509Certificate. Для полной проверки желательно прикрепить весь файл без сокращений. Без сертификата не получится проверить SignatureValue. Если не хотите светить рабочий сертификат на форуме, но подойдет и тестовый.


Все сделал как вы написали ,с этим файлом получилось...Но с другим нет.
Цитата:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="urn://xsd.dmdk.goznak.ru/exchange/2.0" xmlns:ns1="urn://xsd.dmdk.goznak.ru/saleoperation/2.0">
<soapenv:Header></soapenv:Header>
<soapenv:Body>
<ns:SendBatchSaleRequest>
<ns:CallerSignature>
<!--You may enter ANY elements at this point-->
</ns:CallerSignature>
<ns:RequestData id="body">
<ns:sale>
<ns1:index>1</ns1:index>
<ns1:type>SALE</ns1:type>
<ns1:cheque>
<ns1:fn>9960440302599303</ns1:fn>
<ns1:fd>CASH_RECEIPT</ns1:fd>
<ns1:nfd>198</ns1:nfd>
<ns1:date>2023-03-07</ns1:date>
<ns1:uinList>
<ns1:UIN>6432290538021334</ns1:UIN>
</ns1:uinList>
</ns1:cheque>
</ns:sale>
</ns:RequestData>
</ns:SendBatchSaleRequest>
</soapenv:Body>
</soapenv:Envelope>

По идее часть для вычисления hash
Цитата:

<ns:RequestData id="body">
<ns:sale>
<ns1:index>1</ns1:index>
<ns1:type>SALE</ns1:type>
<ns1:cheque>
<ns1:fn>9960440302599303</ns1:fn>
<ns1:fd>CASH_RECEIPT</ns1:fd>
<ns1:nfd>198</ns1:nfd>
<ns1:date>2023-03-07</ns1:date>
<ns1:uinList>
<ns1:UIN>6432290538021334</ns1:UIN>
</ns1:uinList>
</ns1:cheque>
</ns:sale>
</ns:RequestData>


В нормализованном виде
должна быть без разделителей #10 ?
Цитата:

<ns:RequestData xmlns:ns="urn://xsd.dmdk.goznak.ru/exchange/2.0" id="body"><ns:sale><ns1:index>1</ns1:index><ns1:type>SALE</ns1:type><ns1:cheque><ns1:fn>9960440302599303</ns1:fn><ns1:fd>CASH_RECEIPT</ns1:fd><ns1:nfd>198</ns1:nfd><ns1:date>2023-03-07</ns1:date><ns1:uinList><ns1:UIN>6432290538021334</ns1:UIN></ns1:uinList></ns1:cheque></ns:sale></ns:RequestData>

Или в таком?
Цитата:

<ns:RequestData id="body xmlns:ns="urn://xsd.dmdk.goznak.ru/exchange/2.0"">
<ns:sale>
<ns1:index xmlns:ns1="urn://xsd.dmdk.goznak.ru/saleoperation/2.0">1</ns1:index>
<ns1:type xmlns:ns1="urn://xsd.dmdk.goznak.ru/saleoperation/2.0">SALE</ns1:type>
<ns1:cheque xmlns:ns1="urn://xsd.dmdk.goznak.ru/saleoperation/2.0">
<ns1:fn>9960440302599303</ns1:fn>
<ns1:fd>CASH_RECEIPT</ns1:fd>
<ns1:nfd>198</ns1:nfd>
<ns1:date>2023-03-07</ns1:date>
<ns1:uinList>
<ns1:UIN>6432290538021334</ns1:UIN>
</ns1:uinList>
</ns1:cheque>
</ns:sale>
</ns:RequestData>


Но hash должен быть таким
Цитата:

<ds:DigestValue>pSNix646Rn1qGKi58eORPQfYx+TXyMt81IN8hWraaOg=</ds:DigestValue>

Отредактировано пользователем 13 марта 2023 г. 12:35:46(UTC)  | Причина: Не указана
Вверх
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest
2 Страницы<12
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.

Privacy Policy | Форум YAF.NET | YAF.NET © 2003-2024, Yet Another Forum.NET