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

Уведомление

Icon
Error

4 Страницы<1234>
Опции
К последнему сообщению К первому непрочитанному
Offline oleg_kashin  
#11 Оставлено : 5 сентября 2019 г. 18:19:57(UTC)
oleg_kashin

Статус: Участник

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

Сказал(а) «Спасибо»: 4 раз
Вообщем все также проблема с запросом в ГИС ЖКХ - познаний мне явно не хватает
Ранее писал что менял каноникализацию по примерам из запросов по ГОСТ 2001 "http://www.w3.org/TR/2001/REC-xml-c14n-20010315" и у меня запросы проходили...но я ошибался - я всего лишь получал ответ от ГИС ЖКХ, что запрос поставлен на очередь - такая у них схема выполнения асинхронных запросов.
В целом ошибка та же, проблема вероятно в том же -и наверно все так же в каноникализации.
Сидел я тут разбирался и прошел неожиданный ответ от поддержки ГИС ЖКХ, который вообще в ступор поставил:
Цитата:
"Обращаем Ваше внимание, что данная ошибка возникает в результате того, что подпись запроса вычислена некорректна: неверно рассчитано значение "DigestValue" в группе тегов "SigningCertificate"."

Я правильно понимаю что это они бред написали или действительно что-то может быть не так:
1)Вообще просто проверить расчет хэша в этом тэге - что записано в теге X509Certificate после декодировки в base64 взять хэш по urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256 и оно должно совпадать со значением DigestValue.
Ну и собственно все совпадает - совпадает и на пример-запросе от поддержки ГИС ЖКХ
2)"two_oceans" то же это считал...

Кстати этот их ответ про "DigestValue" в группе тегов "SigningCertificate" был после уточняющего вопроса по переписке на их первоначальный ответ:
Цитата:
"SGN000032:Signature verification failed: org.apache.xml.security.exceptions.XMLSecurityException: Invalid digest of reference #xmldsig-8ac47b3d-c066-4507-a734-57fa20918b4b-signedprops

Связанная с этим ошибка «AUT011005 Ошибка формата подписи запроса» возникает в результате того, что подпись запроса не верна: неверно рассчитано значение "DigestValue" . Также просьба убедиться, что текст запроса не был изменён после его подписания. Для успешной отправки запроса не рекомендуется вносить изменения в подписанный запрос."

Я как бы возмутился что в примере, который я им отправлял не было reference с xmldsig-8ac47b3d-c066-4507-a734-57fa20918b4b-signedprops.

Как проверить правильность формирования DigestValue в reference?
Я правильно понимаю что 1 reference
Цитата:
<ds:Reference URI="#a03356a7e8bd4239ad69b3e9c949bca1">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256" />
<ds:DigestValue>DQ77WeXiETaqy2PXD5qTpHa1kiyYkkEUOlacNKAyXJI=</ds:DigestValue>
</ds:Reference>

Формируется для подписываемого тэга hous:exportHouseRequest
Второй для объекта <ds:Object>
Цитата:
<ds:Reference URI="#xmldsig-f865747a-c889-44ff-9d7e-6d58bf5c7979-signedprops" Type="http://uri.etsi.org/01903#SignedProperties">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256" />
<ds:DigestValue>ok93JrGpDcXZfdQmxmZXGreUJOzm5HevXoJNr/qpKMU=</ds:DigestValue>
</ds:Reference>

Он же по коду добавляется при добавлении объекта <ds:Object> он же XadesObject.
Т.е. перед расчетом хэша по указанному алгоритму проводится приведение в соответствии с тем, что задано в ds:Transforms ? Далее результат записывается в ds:DigestValue
Вот что то не понимаю как посмотреть что идет на расчет DigestValue в исходном коде https://github.com/Good-...ibrary/XadesSignedXml.cs строка 1463-1475 вызывается System.Security.Cryptography.Xml.Reference.UpdateHashValue с аргументами m_containingDocument - xmlDocument изначальный,refList - System.Security.Cryptography.Xml.CanonicalXmlNodeList
refList заполняется 1456 - добавляется xml Object после добавления префикса ds. Не понимаю для чего нужен refList и почему ниже не 1483 не делается CanonicalXmlNodeList_Add для reference

Может кто скинет что посмотреть по этому направлению ?- хотя получается судя по ответу ГИС ЖКХ я ошибку ищу не там))
Правильно ли понимаю по каноникализации?
Изначально xml должна быть вся приведена к "http://www.w3.org/2001/10/xml-exc-c14n#" или только при расчете.
как правильно сделать каноникализацию по "http://www.w3.org/2001/10/xml-exc-c14n#", приложение в теме https://www.cryptopro.ru....aspx?g=posts&t=8560 несколько "карежит" мою подписанную xml - это нормально?
Главный вопрос как проверить правильность DigestValue в reference конечно..
Цитата:
Какая фактически выполняется каноникализация - эксклюзивная или неэксклюзивная

Эксклюзивная.
Еще раз пример запроса подписанный во вложении
out (2).xml (9kb) загружен 9 раз(а).
primer 2012.xml (6kb) загружен 8 раз(а).

Отредактировано пользователем 5 сентября 2019 г. 18:23:18(UTC)  | Причина: Не указана

Offline two_oceans  
#12 Оставлено : 6 сентября 2019 г. 6:48:45(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: oleg_kashin Перейти к цитате
В целом ошибка та же, проблема вероятно в том же -и наверно все так же в каноникализации.
Сидел я тут разбирался и прошел неожиданный ответ от поддержки ГИС ЖКХ, который вообще в ступор поставил:
Цитата:
"Обращаем Ваше внимание, что данная ошибка возникает в результате того, что подпись запроса вычислена некорректна: неверно рассчитано значение "DigestValue" в группе тегов "SigningCertificate"."

Я правильно понимаю что это они бред написали или действительно что-то может быть не так:
1)Вообще просто проверить расчет хэша в этом тэге - что записано в теге X509Certificate после декодировки в base64 взять хэш по urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256 и оно должно совпадать со значением DigestValue.
Ну и собственно все совпадает - совпадает и на пример-запросе от поддержки ГИС ЖКХ
2)"two_oceans" то же это считал...

Кстати этот их ответ про "DigestValue" в группе тегов "SigningCertificate" был после уточняющего вопроса по переписке на их первоначальный ответ:
Цитата:
"SGN000032:Signature verification failed: org.apache.xml.security.exceptions.XMLSecurityException: Invalid digest of reference #xmldsig-8ac47b3d-c066-4507-a734-57fa20918b4b-signedprops

Связанная с этим ошибка «AUT011005 Ошибка формата подписи запроса» возникает в результате того, что подпись запроса не верна: неверно рассчитано значение "DigestValue" . Также просьба убедиться, что текст запроса не был изменён после его подписания. Для успешной отправки запроса не рекомендуется вносить изменения в подписанный запрос."

Я как бы возмутился что в примере, который я им отправлял не было reference с xmldsig-8ac47b3d-c066-4507-a734-57fa20918b4b-signedprops.
По порядку: по идее подпись проверяется каскадом - а) проверяется SignatureValue с SignedInfo, если неверно выдается ошибка; б) проверяется каждый reference в SignedInfo на предмет соответствия DigestValue, если неверен выдается ошибка; в) если reference имеет особый тип (как signed properties) в рамках б) после сверки digestValue в Reference проводится проверка и самого текста SignedProperties. То есть если в) дает ошибку, это же считается ошибкой этапа б). Если техподдержка не разбиралась в деталях первый раз, то могут наговорить много ерунды.

Подробнее по в): по значениям Issuer и номеру сертификата выбирается сертификат (то есть перебирается каждый сертификат и декодируется из base64, берутся его свойства) из KeyInfo (этой проверке все равно что он там один!) и если сертифтикат не выбрался, то либо будет исключение либо получится совсем другое значение от пустой строки. Если сертификат выбрался, то действительно считается хэш от декодированного из base64 сертификата как массива байтов (сертификат к канонической форме не приводится). В итоге изначальная ошибка по б) может получиться по следующим причинам:
1. ID на который указывает URI из reference б) не уникален в документе и выбрался неправильный тег вместо signedProperties;
2. в документе нет тега с ID на который указывает URI из reference б).
3. изменение текста signedProperties и его потомков после вычисления хэша от канонической формы signedProperties (тут надо понимать что если каноническая форма signedProperties неэксклюзивная, то на нее повлияют и изменения пространств вышестоящих тегов, не только самого signedProperties и его потомков);
4. неверное вычисление канонической формы signedProperties (эксклюзивную можно проверить той программкой), тут же болтается параметр PreserveWhitespace, который не отражается в xml и надо подбирать при проверке если в xml присутствуют переводы строки и отступы перед тегами;
5. вычисление не той канонической формы signedProperties, что указана в reference б);
6. неверное вычисление хэша от канонической формы signedProperties (как правило маловероятно, но могут быть разные представления одного и того же значения хэша: little endian и big endian);
7. фактический алгоритм хэша от канонической формы signedProperties отличается от указанного в б);
8. неверные значения Issuer или номера сертификата;
9. неверное значение хэша сертификата (аналогично - little endian и big endian);
10. фактический алгоритм хэша сертификата отличается от указанного в signedProperties;
Пункты 1-7 аналогичны для а).

Автор: oleg_kashin Перейти к цитате
Как проверить правильность формирования DigestValue в reference?
Я правильно понимаю что 1 reference ... формируется для подписываемого тэга hous:exportHouseRequest
Правильно, более точно будет сказато что для тега в котором ID соотносится с URI в reference (в цитате из первого референса URI "#a03356a7e8bd4239ad69b3e9c949bca1", значит для тега с ID "a03356a7e8bd4239ad69b3e9c949bca1"). Это должен быть "подписываемый тег".
Автор: oleg_kashin Перейти к цитате
Второй для объекта <ds:Object>
Цитата:
<ds:Reference URI="#xmldsig-f865747a-c889-44ff-9d7e-6d58bf5c7979-signedprops" Type="http://uri.etsi.org/01903#SignedProperties">
Он же по коду добавляется при добавлении объекта <ds:Object> он же XadesObject.
Т.е. перед расчетом хэша по указанному алгоритму проводится приведение в соответствии с тем, что задано в ds:Transforms ? Далее результат записывается в ds:DigestValue
В целом да, сначала трансформы потом вычисление хэша. Обратите внимение, что URI указывает на signedProperties, а не на ds:Object. Более точно сказать, что ds:Object просто обертка, а XadesObject это тег xades:QualifyingProperties и его потомки, так как более продвинутые версии формата Xades включают еще и неподписанные свойства (неподписанные в том смысле, что у них "не наша" подпись и для них не создается reference).

Автор: oleg_kashin Перейти к цитате
Вот что то не понимаю как посмотреть что идет на расчет DigestValue в исходном коде https://github.com/Good-...ibrary/XadesSignedXml.cs строка 1463-1475 вызывается System.Security.Cryptography.Xml.Reference.UpdateHashValue с аргументами m_containingDocument - xmlDocument изначальный,refList - System.Security.Cryptography.Xml.CanonicalXmlNodeList
refList заполняется 1456 - добавляется xml Object после добавления префикса ds. Не понимаю для чего нужен refList и почему ниже не 1483 не делается CanonicalXmlNodeList_Add для reference

Может кто скинет что посмотреть по этому направлению ?- хотя получается судя по ответу ГИС ЖКХ я ошибку ищу не там))
В C# мне немного неудобно разбираться. Как я понимаю, в итоге все идет в базовый объект от Майкрософт, который и вычисляет значения, поэтому нужно включить лог в нем. https://www.cryptopro.ru...&m=105590#post105590

Вообще при подписании последовательность такая - 1) формируем первый референс, применяем трансформы к подписываемому тегу, считаем хэш от результата трансформов, кодируем в base64 и заполняем в референс;
2) формируем второй референс, смотрим что это xades, считаем хэш от сертификата, берем реквизиты сертификата, заполняем SignedProperties;
3) применяем трансформы к signedProperties, считаем хэш от результата трансформов, кодируем в base64 и заполняем в референс;
4) когда все референсы готовы, применяем трансформы к SignedInfo, результат трансформа подписываем (то есть тоже вычисляется хэш, хэш подписывается закрытым ключом, соответствующим сертификату), результат подписи кодируем в base64 и заполняем в SignatureValue;
5) добавляем сертификат в KeyInfo (можно добавить всю цепочку, а не только один сертификат).
Автор: oleg_kashin Перейти к цитате
Правильно ли понимаю по каноникализации?
Изначально xml должна быть вся приведена к "http://www.w3.org/2001/10/xml-exc-c14n#" или только при расчете.
Обязательно - при расчете, изначальный вид задается требованиями ИС, он может или быть каноническим или не быть. Некоторые ИС требуют расположения атрибутов в определенном порядке (отличном от канонического), если не ошибаюсь ГИС ЖКХ как раз из таких и отправить канонический вид изначально не выйдет - после проверки подписи ГИС начнет ругаться на порядок атрибутов. Если бы такого не было - надежнее отправлять сразу каноническую форму с PreserveWhitespace = false, при этом будут выкинуты спорные символы.
Автор: oleg_kashin Перейти к цитате
как правильно сделать каноникализацию по "http://www.w3.org/2001/10/xml-exc-c14n#", приложение в теме https://www.cryptopro.ru....aspx?g=posts&t=8560 несколько "карежит" мою подписанную xml - это нормально?
В принципе нормально, так как изначально форма требуемая ГИС ЖКХ, а не каноническая. В приложение можно вставлять только вычисляемый фрагмент (дополненный объявлениями пространств имен из вышестоящих тегов, на которые ругнется).
Автор: oleg_kashin Перейти к цитате
Главный вопрос как проверить правильность DigestValue в reference конечно..
Цитата:
Какая фактически выполняется каноникализация - эксклюзивная или неэксклюзивная

Эксклюзивная.
Если можно путь в исходнике и номер строки где это нашли.
Автор: oleg_kashin Перейти к цитате
Еще раз пример запроса подписанный во вложении
Например, мне будет гораздо проще проверить если не будет отступа пробелами и перевода строки перед каждым тегом внутри exportNsiListRequest, так как это тоже влияет на каноническую форму (сравните разные PreserveWhilespace в программке).

thanks 1 пользователь поблагодарил two_oceans за этот пост.
oleg_kashin оставлено 10.09.2019(UTC)
Offline two_oceans  
#13 Оставлено : 6 сентября 2019 г. 8:25:32(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
По приложенным файлам: в примере у меня проходит проверка SignatureValue и DigestValue второго референса. С первым референсом похоже у меня какая-то ошибка при удалении комментария - должно быть три перевода строки, а выходит два перевода строки, поэтому наверно хэш примера не сошелся. Сертификат с SignedProperties пока моя программа пока что автоматически не сверяет (предполагается что в работе сертификат проверяется по списку разрешенных), но наверно это будет следующей доработкой - в принципе все реквизиты сертификата вычисляются нету только собственно сверки полей.

По Вашему запросу пока все выдает ошибки, ошибка SignatureValue скорее всего из-за отступов в SignedInfo, позже попробую собрать программу с удалением отступов. в первом референсе видимо тоже. Во втором, помимо прочего мне не нравится что почта указана в виде 1.2.840.113549.1.9.1= вместо стандартного E=. Возможно на компьютере, где производится подписание надо внести изменение в реестр добавляющее имя E оиду 1.2.840.113549.1.9.1
Offline oleg_kashin  
#14 Оставлено : 6 сентября 2019 г. 10:49:32(UTC)
oleg_kashin

Статус: Участник

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

Сказал(а) «Спасибо»: 4 раз
Я нашел это в инструкции ГИС ЖКХ по формированию подписи
Цитата:

При формировании подписи должны использоваться следующие параметры:
Каноникализация - Exclusive XML Canonicalization от 18 июля 2002 - http://www.w3.org/2001/10/xml-exc-c14n#


Цитата:
Например, мне будет гораздо проще проверить если не будет отступа пробелами и перевода строки перед каждым тегом внутри exportNsiListRequest, так как это тоже влияет на каноническую форму (сравните разные PreserveWhilespace в программке).

Попробую - понять бы как это сделать только. Опять же кода много - уже пробовал PreserveWhitespace = false - все равно в результате есть и пробелы и переносы - осталось понять откуда они берутся.
Цитата:
не нравится что почта указана в виде 1.2.840.113549.1.9.1= вместо стандартного E=

Тоже попробую.
Вообще хотелось бы понять как проверить DigestValue и SignatureValue - ушел вникать что пояснил two_oceans

Кстати тестовый пример формирования подписи по ГОСТ 2001, который отправляет ГИС ЖКХ (собственно на нем я и пытаюсь сделать)
Не имеет проверки подписи на борту - все что я видел это проверка срока действия сертификата.
Offline two_oceans  
#15 Оставлено : 6 сентября 2019 г. 11:13:09(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: oleg_kashin Перейти к цитате
Я нашел это в инструкции ГИС ЖКХ по формированию подписи
Вот, а тестовый пример для гост-2001 был написан с другой каноникализацией, поэтому видимо надо найти строку в исходнике и переключить фактически применяемый алгоритм.

Автор: oleg_kashin Перейти к цитате
как проверить DigestValue и SignatureValue - ушел вникать что пояснил two_oceans

Про SignatureValue выше наверно написал неясно, но по аналогии с подписанием
Цитата:
когда все референсы готовы, применяем трансформ к SignedInfo, результат трансформа подписываем (то есть тоже вычисляется хэш, хэш подписывается закрытым ключом, соответствующим сертификату), результат подписи кодируем в base64 и заполняем в SignatureValue;
Проверка в обратную сторону: применяем трансформ CanonicalizationMethod Algorithm к SignedInfo, значение внутри SignatureValue декодируем из base64. Подаем на функцию проверки подписи результат трансформа от SignedInfo (в некоторых случаях подается хэш от результата трансформа), алгоритм хэширования (определяется по части SignatureMethod Algorithm), декодированное значение SignatureValue, сертификат (в данном случае, в стандарте же есть и другие формы задания открытого ключа).
Автор: oleg_kashin Перейти к цитате
Кстати тестовый пример формирования подписи по ГОСТ 2001, который отправляет ГИС ЖКХ (собственно на нем я и пытаюсь сделать)
Не имеет проверки подписи на борту - все что я видел это проверка срока действия сертификата.
Это да, ответы ГИС ЖКХ вначале вообще проверку подписи ответа не проходили, поэтому в примере на это махнули рукой.

Отредактировано пользователем 6 сентября 2019 г. 11:18:29(UTC)  | Причина: Не указана

Offline oleg_kashin  
#16 Оставлено : 6 сентября 2019 г. 13:42:25(UTC)
oleg_kashin

Статус: Участник

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

Сказал(а) «Спасибо»: 4 раз
Цитата:
Вот, а тестовый пример для гост-2001 был написан с другой каноникализацией

да там было "http://www.w3.org/TR/2001/REC-xml-c14n-20010315"
Цитата:
поэтому видимо надо найти строку в исходнике и переключить фактически применяемый алгоритм.

Вот тоже пытаюсь понять это.
единственное место где указывается каноникализация было стр 84 https://github.com/Good-...des/XadesBesSignedXml.cs
Цитата:
SignedInfo.CanonicalizationMethod = XmlDsigCanonicalizationUrl;

Естественно менял XmlDsigCanonicalizationUrl ("http://www.w3.org/TR/2001/REC-xml-c14n-20010315") на XmlDsigExcC14NTransformUrl (оно же "http://www.w3.org/2001/10/xml-exc-c14n#")
Но больше найти не смог...
Кстати по ответу по указанной ошибке поддержкой ГИС ЖКХ точно смотреть ничего не надо - я тут по инету посмотрел они много кому ответили таким же ответом - короче просто шаблон ответа скинули который более или менее подходил видимо
Offline oleg_kashin  
#17 Оставлено : 6 сентября 2019 г. 15:23:22(UTC)
oleg_kashin

Статус: Участник

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

Сказал(а) «Спасибо»: 4 раз
Поддержка опять прислала
Цитата:
Уважаемый пользователь!

Обращаем Ваше внимание, что данная ошибка возникает в результате того, что подпись запроса вычислена некорректна: неверно рассчитано значение "DigestValue" в группе тегов "SigningCertificate".

Блин я перепроверял - получающийся хэш после декодировки X509Certificate сходится
Т.е.
Код:
Convert.ToBase64String(hashAlgorithm.ComputeHash(Convert.FromBase64String("MIIEOzCCA+igAwIBAgITfAAAIl69xb6XX81K7wABAAAiXjAKBggqhQMHAQEDAjCCAQoxGDAWBgUqhQNkARINMTIzNDU2Nzg5MDEyMzEaMBgGCCqFAwOBAwEBEgwwMDEyMzQ1Njc4OTAxLzAtBgNVBAkMJtGD0LsuINCh0YPRidGR0LLRgdC60LjQuSDQstCw0Lsg0LQuIDE4MQswCQYDVQQGEwJSVTEZMBcGA1UECAwQ0LMuINCc0L7RgdC60LLQsDEVMBMGA1UEBwwM0JzQvtGB0LrQstCwMSUwIwYDVQQKDBzQntCe0J4gItCa0KDQmNCf0KLQni3Qn9Cg0J4iMTswOQYDVQQDDDLQotC10YHRgtC+0LLRi9C5INCj0KYg0J7QntCeICLQmtCg0JjQn9Ci0J4t0J/QoNCeIjAeFw0xOTAzMjYxNTQ2MDlaFw0yMDAzMjYxNTU2MDlaMBExDzANBgNVBAMMBnF3ZXF3ZTBmMB8GCCqFAwcBAQEBMBMGByqFAwICJAAGCCqFAwcBAQICA0MABEAITPXfzlPyUvEdyIu9xdiJ3/pyWoyPpJGSnpB2tcOmDSKgY820V6aGKoCRbD+7ERfyFmj7mDagaPpCmE4gh77go4ICFTCCAhEwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBTmibcoo8HRfZ6tV6Gqye6Y7slQVjAfBgNVHSMEGDAWgBSbhV77gdxNWQdRY8++39osf8lEPDCBzAYDVR0fBIHEMIHBMIG+oIG7oIG4hoG1aHR0cDovL3Rlc3Rnb3N0MjAxMi5jcnlwdG9wcm8ucnUvQ2VydEVucm9sbC8hMDQyMiEwNDM1ITA0NDEhMDQ0MiEwNDNlITA0MzIhMDQ0YiEwNDM5JTIwITA0MjMhMDQyNiUyMCEwNDFlITA0MWUhMDQxZSUyMCEwMDIyITA0MWEhMDQyMCEwNDE4ITA0MWYhMDQyMiEwNDFlLSEwNDFmITA0MjAhMDQxZSEwMDIyKDEpLmNybDCB2gYIKwYBBQUHAQEEgc0wgcowRAYIKwYBBQUHMAKGOGh0dHA6Ly90ZXN0Z29zdDIwMTIuY3J5cHRvcHJvLnJ1L0NlcnRFbnJvbGwvcm9vdDIwMTguY3J0MD8GCCsGAQUFBzABhjNodHRwOi8vdGVzdGdvc3QyMDEyLmNyeXB0b3Byby5ydS9vY3NwMjAxMmcvb2NzcC5zcmYwQQYIKwYBBQUHMAGGNWh0dHA6Ly90ZXN0Z29zdDIwMTIuY3J5cHRvcHJvLnJ1L29jc3AyMDEyZ3N0L29jc3Auc3JmMAoGCCqFAwcBAQMCA0EAshoiXbdKE+B6G5+gvvb7XamJAjsQPfDbzKAbotvhfYn7e9fmBKs6JugN8/4RR+P20wblrW3lcSsFPATGrX+ZKw==")))

Дает результат который указан в тестовом примере запроса "HNGQRbX8zzFa9F9Qg7jOO8urNG93+9AYuyEG9dVfgUA="
Т.е. логично что у меня должно быть все гуд

Отредактировано пользователем 10 сентября 2019 г. 0:10:23(UTC)  | Причина: Не указана

Offline two_oceans  
#18 Оставлено : 9 сентября 2019 г. 8:30:32(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: oleg_kashin Перейти к цитате
Поддержка опять прислала
Цитата:
Уважаемый пользователь! Обращаем Ваше внимание, что данная ошибка возникает в результате того, что подпись запроса вычислена некорректна: неверно рассчитано значение "DigestValue" в группе тегов "SigningCertificate".

Блин я перепроверял - получающийся хэш после декодировки X509Certificate сходится
Т.е. Convert.ToBase64String(hashAlgorithm.ComputeHash(Convert.FromBase64String("MII...ZKw==")))
Дает результат который указан в тестовом примере запроса "HNGQRbX8zzFa9F9Qg7jOO8urNG93+9AYuyEG9dVfgUA="
Т.е. логично что у меня должно быть все гуд
Длинные строки в сообщениях форума лучше заключать в тег code=markup (при написании сообщения выше кнопка "Выберите тип подсветки кода"-"Plain text") иначе страница форума искажается.

От приведенного в прошлом сообщении сертификата тестового центра действительно такое значение хэша.
1CD19045B5FCCF315AF45F5083B8CE3BCBAB346F77FBD018BB2106F5D55F8140
HNGQRbX8zzFa9F9Qg7jOO8urNG93+9AYuyEG9dVfgUA=
Однако в "out (2).xml" указан другой сертификат на ООО ***-КОСТРОМА с хэшем
88782576451F619BAB9B5FCE01B6C5143A96728C711E0B6651C6D50445952A55
iHgldkUfYZurm1/OAbbFFDqWcoxxHgtmUcbVBEWVKlU=

Цитата:
единственное место где указывается каноникализация было стр 84 https://github.com/Good-...des/XadesBesSignedXml.cs
Строка влияет на SignedInfo, должны быть еще трансформы для референсов. Например,
https://github.com/Good-...ns/GostCryptoProvider.cs стр 84 и где правили второй трансформ по идее тоже должно быть (или по крайней мере, Вы в своем коде добавляли каноникализацию второго референса): https://github.com/Good-...ibrary/XadesSignedXml.cs или https://github.com/Good-...ns/GostCryptoProvider.cs или https://github.com/Good-...e/Library/XadesObject.cs В этих местах мелькает и PreserveWhitespace = true

Еще вот: https://github.com/Good-...lXmlDsigC14NTransform.cs стр 14 и 16 Надо полагать, это патч каноникализации для дотнет 3.5, ссылка на https://www.cryptopro.ru...=57702&find=lastpost

Насчет E= похоже здесь https://github.com/Good-...ations/IssuerComparer.cs стр 19 замена на оид

UPD: Исправил у себя обработку комментариев при каноникализации - теперь пример из сообщения 11проходит проверку и значения подписи и референсов (без проверки полей QualifyingProperties пока).

Отредактировано пользователем 9 сентября 2019 г. 12:57:18(UTC)  | Причина: Не указана

thanks 1 пользователь поблагодарил two_oceans за этот пост.
oleg_kashin оставлено 10.09.2019(UTC)
Offline oleg_kashin  
#19 Оставлено : 10 сентября 2019 г. 0:55:07(UTC)
oleg_kashin

Статус: Участник

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

Сказал(а) «Спасибо»: 4 раз
Цитата:
Длинные строки в сообщениях форума лучше заключать в тег code=markup (при написании сообщения выше кнопка "Выберите тип подсветки кода"-"Plain text") иначе страница форума искажается.

Да..соррян я поправил
Цитата:
Строка влияет на SignedInfo, должны быть еще трансформы для референсов. Например,
https://github.com/Good-...ns/GostCryptoProvider.cs стр 84 и где правили второй трансформ по идее тоже должно быть (или по крайней мере, Вы в своем коде добавляли каноникализацию второго референса): https://github.com/Good-...ibrary/XadesSignedXml.cs или https://github.com/Good-...ns/GostCryptoProvider.cs или https://github.com/Good-...e/Library/XadesObject.cs В этих местах мелькает и PreserveWhitespace = true

Трансформ для второго референса добавлял вручную вот тут вручную при добавлении Object https://github.com/Good-...ibrary/XadesSignedXml.cs стр 511.
Цитата:
Однако в "out (2).xml" указан другой сертификат на ООО ***-КОСТРОМА с хэшем
88782576451F619BAB9B5FCE01B6C5143A96728C711E0B6651C6D50445952A55
iHgldkUfYZurm1/OAbbFFDqWcoxxHgtmUcbVBEWVKlU=

Это как раз мой) - пофиг на стал его сркывать)

PreserveWhitespace'ы убрал - да я видел их но понять не мог как посмотреть что именно идет на расчет DigestValue
Вот что заметил странное - нашел SignedXmlDebugLog.LogReferenceData (хотя наверно это только для меня открытие) https://referencesource....ence.cs,1793891262c64346
Включил дебаг и на расчет Digest второго реферанс идут данные явно отличные от того, что есть в итоговой xml
Например данные по 2 реферансу
Код:

System.Security.Cryptography.Xml.SignedXml Verbose: 8 : [Reference#00245fb7, ReferenceData] Преобразованный контент ссылки: <xades:SignedProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Id="xmldsig-e79f5b13-3d1c-4648-b147-dd08f6fcb807-signedprops"><xades:SignedSignatureProperties><xades:SigningTime>2019-09-10T00:05:17.359+03:00</xades:SigningTime><xades:SigningCertificate><xades:Cert><xades:CertDigest><DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"></DigestMethod><ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">iHgldkUfYZurm1/OAbbFFDqWcoxxHgtmUcbVBEWVKlU=</ds:DigestValue></xades:CertDigest><xades:IssuerSerial><ds:X509IssuerName xmlns:ds="http://www.w3.org/2000/09/xmldsig#">1.2.840.113549.1.9.1=ca_tensor@tensor.ru,1.2.643.100.1=1027600787994,1.2.643.3.131.1.1=007605016030,C=RU,ST=76 Ярославская область,L=г. Ярославль,STREET=Московский проспект д.12,OU=Удостоверяющий центр,O=ООО \"КОМПАНИЯ \"ТЕНЗОР\",CN=ООО \"КОМПАНИЯ \"ТЕНЗОР\"</ds:X509IssuerName><ds:X509SerialNumber xmlns:ds="http://www.w3.org/2000/09/xmldsig#">51038696132506063092011207922305402410</ds:X509SerialNumber></xades:IssuerSerial></xades:Cert></xades:SigningCertificate></xades:SignedSignatureProperties></xades:SignedProperties>

а в итоговой он выглядит как
Цитата:
<xades:SignedProperties Id="xmldsig-e79f5b13-3d1c-4648-b147-dd08f6fcb807-signedprops">
<xades:SignedSignatureProperties>
<xades:SigningTime>2019-09-10T00:05:17.359+03:00</xades:SigningTime>
<xades:SigningCertificate>
<xades:Cert>
<xades:CertDigest>
<DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256" />
<ds:DigestValue>iHgldkUfYZurm1/OAbbFFDqWcoxxHgtmUcbVBEWVKlU=</ds:DigestValue>
</xades:CertDigest>
<xades:IssuerSerial>
<ds:X509IssuerName>1.2.840.113549.1.9.1=ca_tensor@tensor.ru,1.2.643.100.1=1027600787994,1.2.643.3.131.1.1=007605016030,C=RU,ST=76 Ярославская область,L=г. Ярославль,STREET=Московский проспект д.12,OU=Удостоверяющий центр,O=ООО \"КОМПАНИЯ \"ТЕНЗОР\",CN=ООО \"КОМПАНИЯ \"ТЕНЗОР\"</ds:X509IssuerName>
<ds:X509SerialNumber>51038696132506063092011207922305402410</ds:X509SerialNumber>
</xades:IssuerSerial>
</xades:Cert>
</xades:SigningCertificate>
</xades:SignedSignatureProperties>
</xades:SignedProperties>


Т.е. разница в куче namespace которые появляются при сборке xml в 1 и втором случае. Как я понимаю это может быть причиной почему по второму Reference DigestValue не сходится?
Цитата:
Еще вот: https://github.com/Good-...lXmlDsigC14NTransform.cs стр 14 и 16 Надо полагать, это патч каноникализации для дотнет 3.5, ссылка на https://www.cryptopro.ru...=57702&find=lastpost

У меня исходники с гита были скачаны еще в 16 году...у меня даже этого коммита нет)

Цитата:
UPD: Исправил у себя обработку комментариев при каноникализации - теперь пример из сообщения 11проходит проверку и значения подписи и референсов (без проверки полей QualifyingProperties пока).

Я как понимаю Вы проверяли primer 2012.xml (6kb) из сообщения 11 - подписанный тестовым ключом? Во вложении подписанный запрос whitespace out.xml (9kb) загружен 2 раз(а). Если есть возможность посмотреть - как я надеюсь беда именно со вторым референс.

Хотел было уже написать что может поддержка ГИС ЖКХ была от части права - только в сломанный телефон сыграли - хотели написать что DigestValue который по группе SignedProperties не верно рассчитан, но тут они прислали вот что неожиданно, не в тему что и так понятно
Цитата:
DigestValue содержит base64 закодированный хэш от данных на которые он ссылается, в соответствии с https://www.etsi.org/del...0/ts_101903v010402p.pdf.

Ну это так к слову....

Offline two_oceans  
#20 Оставлено : 10 сентября 2019 г. 6:37:50(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: oleg_kashin Перейти к цитате
PreserveWhitespace'ы убрал - да я видел их но понять не мог как посмотреть что именно идет на расчет DigestValue
Вот что заметил странное - ... включил дебаг и на расчет Digest второго реферанс идут данные явно отличные от того, что есть в итоговой xml. Например данные по 2 реферансу ... а в итоговой он выглядит как ...
Т.е. разница в куче namespace которые появляются при сборке xml в 1 и втором случае. Как я понимаю это может быть причиной почему по второму Reference DigestValue не сходится?
Конечно, это может быть причиной, однако в данном случае namespace добавлены верно, но еще одного не хватает в DigestMethod.
Ненормально 2 факта: 1) в итоговом документе присутствую отступы пробелами перед тегами и переводы строк, а на отладке расчета DigestValue они отсутствуют (опять PreserveWhitespace... что-то мне кажется без точного понимания откуда что идет его изменение сделает только хуже, так как в коде тьма методов GetXml и надо похоже найти все и явно указать PreserveWhitespace); 2) тег DigestMethod без префикса и namespace, судя потому что каноническая форма его не изменила, попал вообще в default namespace. Это может привести к тому, что при проверке тег DigestMethod не найдется из-за различающегося namespace и будет выбран неизвестно какой алгоритм "по умолчанию" для расчета хэша сертификата (гост-2001, например). Странно, что в сообщении 11 файл "out (2).xml" был с правильным DigestMethod для сертификата.
Автор: oleg_kashin Перейти к цитате
Я как понимаю Вы проверяли primer 2012.xml (6kb) из сообщения 11 - подписанный тестовым ключом? Во вложении подписанный запрос whitespace out.xml Если есть возможность посмотреть - как я надеюсь беда именно со вторым референс.
Да, прошел primer 2012.xml. В out.xml пока ругается на все: как выяснилось отступы сделаны пробелами, а не табуляцией (мой дополнительный фильтр настроен на табуляции), то есть придется сделать аккуратную вырезку текстовых узлов в которых все символы с кодами меньше или равны пробелу (как в смэв 3 трансформе). Где-то бы найти хорошее пояснение по whitespace.
Автор: oleg_kashin Перейти к цитате
Хотел было уже написать что может поддержка ГИС ЖКХ была от части права - только в сломанный телефон сыграли - хотели написать что DigestValue который по группе SignedProperties не верно рассчитан
Ах да, это же ГИС ЖКХ, Вам достаточно долго удавалось попасть на кого-то относительно вменяемого в техподдержке, а теперь попался еще больший "попугайчик". Если проблема из-за DigestMethod для сертификата, то они вообще почти правильно сказали про DigestValue сертификата, только тег соседний на самом деле.

Отредактировано пользователем 10 сентября 2019 г. 7:08:46(UTC)  | Причина: Не указана

thanks 1 пользователь поблагодарил two_oceans за этот пост.
oleg_kashin оставлено 10.09.2019(UTC)
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
4 Страницы<1234>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.