logo Обзор КриптоПро NGate для защищённого доступа к корпоративным ресурсам
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

2 Страницы12>
Опции
К последнему сообщению К первому непрочитанному
Offline oleg_kashin  
#1 Оставлено : 4 августа 2019 г. 16:24:07(UTC)
oleg_kashin

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

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

Сказал(а) «Спасибо»: 4 раз
Помогите разобраться с подписью запросов к сервису ГИС ЖКХ с использованием ключа по ГОСТ2012
Раньше использовался c ключом по ГОСТу2001 код на основе https://github.com/Good-...itan/signature-demo-net.

Переделка исходного приложения с заменой алгоритмов хэширования,подписи с XmlDsigGost3410UrlObsolete, XmlDsigGost3411UrlObsolete на XmlDsigGost3410_2012_256Url,XmlDsigGost3411_2012_256Url и заменой на Gost3410_2012_256CryptoServiceProvider дала странный результат
Пример подписанной xml:
Цитата:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:base="http://dom.gosuslugi.ru/schema/integration/base/" xmlns:hous="http://dom.gosuslugi.ru/schema/integration/house-management/" xmlns:xd="http://www.w3.org/2000/09/xmldsig#">
<soapenv:Header>
<base:RequestHeader>
<base:Date>2019-08-01T08:32:00</base:Date>
<base:MessageGUID>ac7f5e9d-4cf9-4429-ab08-6fa101a38929</base:MessageGUID>
<base:orgPPAGUID>6a211b53-14ba-4e5d-bff1-8904d043df3a</base:orgPPAGUID>
<base:IsOperatorSignature>true</base:IsOperatorSignature>
</base:RequestHeader>
</soapenv:Header>
<soapenv:Body>
<hous:exportHouseRequest Id="a06356a7e8bd4239ad69b3e9c949bca1" base:version="11.1.0.1">
<ds:Signature Id="xmldsig-3d1d7b14-2b97-4bbe-8339-9ccccab268e1" 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 Id="xmldsig-3d1d7b14-2b97-4bbe-8339-9ccccab268e1-ref0" URI="#a06356a7e8bd4239ad69b3e9c949bca1">
<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>C9l5Lyvrl3WzoRXt41#########################</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#xmldsig-3d1d7b14-2b97-4bbe-8339-9ccccab268e1-signedprops" Type="http://uri.etsi.org/01903#SignedProperties">
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr3411" />
<ds:DigestValue>L+T/JbBKI5lB5f1###################################</ds:DigestValue>
</ds:Reference>

</ds:SignedInfo>
<ds:SignatureValue Id="xmldsig-3d1d7b14-2b97-4bbe-8339-9ccccab268e1-sigvalue">H8hnQlUYXlbuH4Hhzlteu0kPI/usmt2Z4sLv2Nr0####################</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIL4zCCC5CgAwIBAgIQJmWyAISqNbZKeXNvjv8GKjAKBggqhQMHAQEDAjCCAYcxIjAgBgkqhkiG9w0BCQEWE2NhX3RlbnNvckB0ZW5zb3IucnUxGDAWBgUqhQNkARINMTAyNzYwMDc4Nzk5NDEaMBgGCCqFAwOBAwEBEgwwMDc2MDUwMTYwMzAxCzAJBgNVBAYTAlJVMTEwLwYDVQQIDCg3NiDQr9GA0L7Rgd.............</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
<ds:Object>
<xades:QualifyingProperties Target="#xmldsig-3d1d7b14-2b97-4bbe-8339-9ccccab268e1" xmlns:xades141="http://uri.etsi.org/01903/v1.4.1#" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#">
<xades:SignedProperties Id="xmldsig-3d1d7b14-2b97-4bbe-8339-9ccccab268e1-signedprops">
<xades:SignedSignatureProperties>
<xades:SigningTime>2019-08-03T18:52:58.535+03:00</xades:SigningTime>
<xades:SigningCertificate>
<xades:Cert>
<xades:CertDigest>
<ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256" />
<ds:DigestValue>iHgldkUfYZurm1/OAbbFFDq#####################=</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>5103869613250..................</ds:X509SerialNumber>
</xades:IssuerSerial>
</xades:Cert>
</xades:SigningCertificate>
</xades:SignedSignatureProperties>
</xades:SignedProperties>
</xades:QualifyingProperties>
</ds:Object>
</ds:Signature>
<hous:FIASHouseGuid>23159e35-673f-4b45-952f-b80bbd5f4110</hous:FIASHouseGuid>
</hous:exportHouseRequest>
</soapenv:Body>
</soapenv:Envelope>


Запрос сервисами принимается, но при получении результата выходит ошибка "Ошибка формата подписи запроса".Не очень понимаю в чем проблема, но кажется в выделенном выше Reference - откуда то берется gost3411.
По документации ГИС ЖКХ подпись должна быть по примеру:
Цитата:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Header>
<h:RequestHeader xmlns="http://dom.gosuslugi.ru/schema/integration/8.5.0.4/" xmlns:h="http://dom.gosuslugi.ru/schema/integration/8.5.0.4/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!-- Заголовок, содержащий информацию о поставщике данных и сообщении-->
<Date>2016-01-29T09:29:29.5033083+03:00</Date>
<MessageGUID>${=java.util.UUID.randomUUID()}</MessageGUID>
<orgPPAGUID>a013da6b-fd11-4b20-8903-dbbcb22ff221</orgPPAGUID>
</h:RequestHeader>
</s:Header>
<s:Body xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<exportNsiListRequest xmlns="http://dom.gosuslugi.ru/schema/integration/8.5.0.4/nsi/" Id="foo">
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="xmldsig-3f222eb1-bfe9-4da6-a121-450a984fc85c">
<!-- Элемент, содержащий электронную подпись поставщика данных -->
<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="#foo">
<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>RML7HeI83whzrRjK3S02X4MlVGrSIIWHVC3x3la+IZc=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#xmldsig-3f222eb1-bfe9-4da6-a121-450a984fc85c-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>oYIU+RWjn9wSku3ixrJy48TMqRU4geh9HE4LLL7lmhk=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>alQ98eCzqfxzOM66D9oqXqibLpT7n9epRju90+98TVDCh1Pyu365QcBWbd8mYMpzvb5nhYdhK5YMsgZQ8y/2EA==</ds:SignatureValue>
<ds:KeyInfo Id="xmldsig-61b74cb4-68b2-439c-9533-8668dc82d1dd">
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Certificate>MIIEOzCCA+igAwIBAgITfAAAIl69xb6XX81K7wABAAAiXjAKBggqhQMHAQEDAjCCAQoxGDAWBgUq
hQNkARINMTIzNDU2Nzg5MDEyMzEaMBgGCCqFAwOBAwEBEgwwMDEyMzQ1Njc4OTAxLzAtBgNVBAkM
JtGD0LsuINCh0YPRidGR0LLRgdC60LjQuSDQstCw0Lsg0LQuIDE4MQswCQYDVQQGEwJSVTEZMBcG
A1UECAwQ0LMuINCc0L7RgdC60LLQsDEVMBMGA1UEBwwM0JzQvtGB0LrQstCwMSUwIwYDVQQKDBzQ
ntCe0J4gItCa0KDQmNCf0KLQni3Qn9Cg0J4iMTswOQYDVQQDDDLQotC10YHRgtC+0LLRi9C5INCj
0KYg0J7QntCeICLQmtCg0JjQn9Ci0J4t0J/QoNCeIjAeFw0xOTAzMjYxNTQ2MDlaFw0yMDAzMjYx
NTU2MDlaMBExDzANBgNVBAMMBnF3ZXF3ZTBmMB8GCCqFAwcBAQEBMBMGByqFAwICJAAGCCqFAwcB
AQICA0MABEAITPXfzlPyUvEdyIu9xdiJ3/pyWoyPpJGSnpB2tcOmDSKgY820V6aGKoCRbD+7ERfy
Fmj7mDagaPpCmE4gh77go4ICFTCCAhEwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUF
BwMCMB0GA1UdDgQWBBTmibcoo8HRfZ6tV6Gqye6Y7slQVjAfBgNVHSMEGDAWgBSbhV77gdxNWQdR
Y8++39osf8lEPDCBzAYDVR0fBIHEMIHBMIG+oIG7oIG4hoG1aHR0cDovL3Rlc3Rnb3N0MjAxMi5j
cnlwdG9wcm8ucnUvQ2VydEVucm9sbC8hMDQyMiEwNDM1ITA0NDEhMDQ0MiEwNDNlITA0MzIhMDQ0
YiEwNDM5JTIwITA0MjMhMDQyNiUyMCEwNDFlITA0MWUhMDQxZSUyMCEwMDIyITA0MWEhMDQyMCEw
NDE4ITA0MWYhMDQyMiEwNDFlLSEwNDFmITA0MjAhMDQxZSEwMDIyKDEpLmNybDCB2gYIKwYBBQUH
AQEEgc0wgcowRAYIKwYBBQUHMAKGOGh0dHA6Ly90ZXN0Z29zdDIwMTIuY3J5cHRvcHJvLnJ1L0Nl
cnRFbnJvbGwvcm9vdDIwMTguY3J0MD8GCCsGAQUFBzABhjNodHRwOi8vdGVzdGdvc3QyMDEyLmNy
eXB0b3Byby5ydS9vY3NwMjAxMmcvb2NzcC5zcmYwQQYIKwYBBQUHMAGGNWh0dHA6Ly90ZXN0Z29z
dDIwMTIuY3J5cHRvcHJvLnJ1L29jc3AyMDEyZ3N0L29jc3Auc3JmMAoGCCqFAwcBAQMCA0EAshoi
XbdKE+B6G5+gvvb7XamJAjsQPfDbzKAbotvhfYn7e9fmBKs6JugN8/4RR+P20wblrW3lcSsFPATG
rX+ZKw==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
<ds:Object>
<xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" Target="#xmldsig-3f222eb1-bfe9-4da6-a121-450a984fc85c">
<xades:SignedProperties Id="xmldsig-3f222eb1-bfe9-4da6-a121-450a984fc85c-signedprops">
<xades:SignedSignatureProperties>
<xades:SigningTime>2019-04-18T12:39:59.239+03:00</xades:SigningTime>
<xades:SigningCertificate>
<xades:Cert>
<xades:CertDigest>
<ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"/>
<ds:DigestValue>HNGQRbX8zzFa9F9Qg7jOO8urNG93+9AYuyEG9dVfgUA=</ds:DigestValue>
</xades:CertDigest>
<xades:IssuerSerial>
<ds:X509IssuerName>cn=Тестовый УЦ ООО \"КРИПТО-ПРО\",o=ООО \"КРИПТО-ПРО\",l=Москва,st=г. Москва,c=RU,street=ул. Сущёвский вал д.18,1.2.643.3.131.1.1=001234567890,1.2.643.100.1=1234567890123</ds:X509IssuerName>
<ds:X509SerialNumber>2765292450303474073288100094019649762249155166</ds:X509SerialNumber>
</xades:IssuerSerial>
</xades:Cert>
</xades:SigningCertificate>
</xades:SignedSignatureProperties>
</xades:SignedProperties>
</xades:QualifyingProperties>
</ds:Object>
</ds:Signature>
<!--Элемент, описывающий бизнес-данные-->
</exportNsiListRequest>
</s:Body>
</s:Envelope>



Пробовал подписывать xml в соответствии с примерами по КриптоПро .net из \simple\Xml\cs\SignSmevRequest.cs и SignNode.cs
Код типа
Цитата:

// Создаем новый документ XML.
XmlDocument doc = new XmlDocument();

// Читаем документ из файла.
doc.Load(new XmlTextReader(FileName));

// Создаём объект SmevSignedXml - наследник класса SignedXml с перегруженным GetIdElement
// для корректной обработки атрибута wsu:Id.
SmevSignedXml signedXml = new SmevSignedXml(doc);

// Задаём ключ подписи для документа SmevSignedXml.
signedXml.SigningKey = Certificate.PrivateKey;

// Создаем ссылку на подписываемый узел XML. В данном примере и в методических
// рекомендациях СМЭВ подписываемый узел soapenv:Body помечен идентификатором "body".
Reference reference = new Reference();
reference.Uri = "#a06356a7e8bd4239ad69b3e9c949bca1";

// Задаём алгоритм хэширования подписываемого узла - ГОСТ Р 34.11-94. Необходимо
// использовать устаревший идентификатор данного алгоритма, т.к. именно такой
// идентификатор используется в СМЭВ.
#pragma warning disable 612
//warning CS0612: 'CryptoPro.Sharpei.Xml.CPSignedXml.XmlDsigGost3411UrlObsolete' is obsolete
reference.DigestMethod = CryptoPro.Sharpei.Xml.CPSignedXml.XmlDsigGost3411_2012_256Url;
#pragma warning restore 612

// Добавляем преобразование для приведения подписываемого узла к каноническому виду
// по алгоритму http://www.w3.org/2001/10/xml-exc-c14n# в соответствии с методическими
// рекомендациями СМЭВ.
// XmlDsigExcC14NTransform c14 = new XmlDsigExcC14NTransform();XmlDsigCanonicalizationUrl
reference.AddTransform(new XmlDsigExcC14NTransform());
reference.AddTransform(new XmlDsigEnvelopedSignatureTransform());

// Добавляем ссылку на подписываемый узел.
signedXml.AddReference(reference);

// Задаём преобразование для приведения узла ds:SignedInfo к каноническому виду
// по алгоритму http://www.w3.org/2001/10/xml-exc-c14n# в соответствии с методическими
// рекомендациями СМЭВ.
signedXml.SignedInfo.CanonicalizationMethod = SignedXml.XmlDsigExcC14NTransformUrl;

// Задаём алгоритм подписи - ГОСТ Р 34.10-2001. Необходимо использовать устаревший
// идентификатор данного алгоритма, т.к. именно такой идентификатор используется в
// СМЭВ.
#pragma warning disable 612
//warning CS0612: 'CryptoPro.Sharpei.Xml.CPSignedXml.XmlDsigGost3411UrlObsolete' is obsolete
signedXml.SignedInfo.SignatureMethod = CryptoPro.Sharpei.Xml.CPSignedXml.XmlDsigGost3410_2012_256Url;
#pragma warning restore 612
// Создаем объект KeyInfo.
KeyInfo keyInfo = new KeyInfo();

// Добавляем сертификат в KeyInfo
keyInfo.AddClause(new KeyInfoX509Data(Certificate));

// Добавляем KeyInfo в SignedXml.
signedXml.KeyInfo = keyInfo;
// Вычисляем подпись.
signedXml.ComputeSignature();

// Получаем представление подписи в виде XML.
XmlElement xmlDigitalSignature = signedXml.GetXml();

var signedDataContainer = signedXml.GetIdElement(doc, "a06356a7e8bd4239ad69b3e9c949bca1");
signedDataContainer.InsertBefore(doc.ImportNode(xmlDigitalSignature, true), signedDataContainer.FirstChild);




Получаться что то типа
Цитата:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:base="http://dom.gosuslugi.ru/schema/integration/base/" xmlns:hous="http://dom.gosuslugi.ru/schema/integration/house-management/" xmlns:xd="http://www.w3.org/2000/09/xmldsig#">
<soapenv:Header>
<base:RequestHeader>
<base:Date>2019-08-01T08:32:00</base:Date>
<base:MessageGUID>ac7f5e9d-4cf9-4429-ab08-6fa101a38968</base:MessageGUID>
<base:orgPPAGUID>6a211b###############################</base:orgPPAGUID>
<base:IsOperatorSignature>true</base:IsOperatorSignature>
</base:RequestHeader>
</soapenv:Header>
<soapenv:Body>
<hous:exportHouseRequest Id="a06356a7e8bd4239ad69b3e9c949bca1" base:version="11.1.0.1">
<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="#a06356a7e8bd4239ad69b3e9c949bca1">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
</Transforms>
<DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256" />
<DigestValue>9G3SK46aX/tJ################</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>zBt2vj62RRGNVHX8CBhuJ2le4lez6QWhO##############################
</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIIL4zCCC5CgAwIBAgIQJmWyAISqNbZKeXNvjv8GKjAKBggqhQMHAQEDAjCCAY/.....
</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<hous:FIASHouseGuid>23159e35-673f-4b45-952f-b80bbd5f4110</hous:FIASHouseGuid>
</hous:exportHouseRequest>
</soapenv:Body>
</soapenv:Envelope>

Нет в xml <ds:Object> и соответственно QualifyingProperties,SignedProperties и т.д. xml естественно не проходит с той же ошибкой
Подскажите как создаются это объекты или кто делал рабочий пример подписи запроса в ГИС ЖКХ с ключом ГОСТ2001????Ключи по ГОСТ2001 скоро закончатся...

Online two_oceans  
#2 Оставлено : 5 августа 2019 г. 11:44:28(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 42 раз
Поблагодарили: 146 раз в 139 постах
Добрый день.
Суммируя Ваш Вопрос:
1) В первом примере на основе примера подписания xades-bes для гис жкх с гитхаба меняется алгоритм хэша первого референса (от подписываемого текст) и подписи, хэш сертификата, но не меняется алгоритм хэша второго референса (данные xades). Вам нужно найти в исходнике место, задается алгоритм хэша второго референса и также поменять его на гост-2012. После этого должно все получиться по примеру.

Код:
Предположительно Вы поменяли на гост-2012 тут:
signature-demo-net/blob/master/Xades/Implementations/GostCryptoProvider.cs
и осталось поменять вот здесь
signature-demo-net/blob/master/Xades-master/Source/Library/XadesSignedXml.cs
в AddXadesObject прописан явно алгоритм второго референса.


2) С подписанием через СМЭВ тоже все логично: СМЭВ не требует подписи формата xades-bes поэтому второй референс и ds:Object отсутствуют в подписи. Нужно создать XadesObject, добавить его в подпись. Подробнее в приведенной Вами ссылке на гитхаб:
Код:
signature-demo-net/blob/master/Xades/XadesBesSignedXml.cs
  public void ComputeSignature(X509Certificate2 certificate, string privateKeyPassword)
signature-demo-net/blob/master/Xades/Implementations/GostCryptoProvider.cs
  public XadesObject GetXadesObject(XadesInfo xadesInfo, string signatureId)
signature-demo-net/blob/master/Xades-master/Source/Library/XadesSignedXml.cs
  public void AddXadesObject(XadesObject xadesObject)

Offline oleg_kashin  
#3 Оставлено : 6 августа 2019 г. 22:39:00(UTC)
oleg_kashin

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

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

Сказал(а) «Спасибо»: 4 раз
Автор: two_oceans Перейти к цитате
Добрый день.
Суммируя Ваш Вопрос:
1) В первом примере на основе примера подписания xades-bes для гис жкх с гитхаба меняется алгоритм хэша первого референса (от подписываемого текст) и подписи, хэш сертификата, но не меняется алгоритм хэша второго референса (данные xades). Вам нужно найти в исходнике место, задается алгоритм хэша второго референса и также поменять его на гост-2012. После этого должно все получиться по примеру.

Код:
Предположительно Вы поменяли на гост-2012 тут:
signature-demo-net/blob/master/Xades/Implementations/GostCryptoProvider.cs
и осталось поменять вот здесь
signature-demo-net/blob/master/Xades-master/Source/Library/XadesSignedXml.cs
в AddXadesObject прописан явно алгоритм второго референса.


2) С подписанием через СМЭВ тоже все логично: СМЭВ не требует подписи формата xades-bes поэтому второй референс и ds:Object отсутствуют в подписи. Нужно создать XadesObject, добавить его в подпись. Подробнее в приведенной Вами ссылке на гитхаб:
Код:
signature-demo-net/blob/master/Xades/XadesBesSignedXml.cs
  public void ComputeSignature(X509Certificate2 certificate, string privateKeyPassword)
signature-demo-net/blob/master/Xades/Implementations/GostCryptoProvider.cs
  public XadesObject GetXadesObject(XadesInfo xadesInfo, string signatureId)
signature-demo-net/blob/master/Xades-master/Source/Library/XadesSignedXml.cs
  public void AddXadesObject(XadesObject xadesObject)



По 1) да действительно все так и есть как Вы описали - даже не знаю почему AddXadesObject в XadesSignedXml.cs пропустил reference.DigestMethod = "http://www.w3.org/2001/04/xmldsig-more#gostr3411" а в GostCryptoProvider.cs все исправил
По 2) я так и понял что в итоге все получится почти также как и в п.1)
Спасибо)
Offline oleg_kashin  
#4 Оставлено : 11 августа 2019 г. 17:06:31(UTC)
oleg_kashin

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

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

Сказал(а) «Спасибо»: 4 раз
короче прошла еще неделя)
Указанный второй reference signature-demo-net/blob/master/Xades-master/Source/Library/XadesSignedXml.cs поправил при создании Xadesobject - теперь <signature> в xml ничем принципиально не отличается от примера с сайта ГИС ЖКХ, но запрос опять не проходит с ошибкой "Ошибка формата подписи запроса".
Писал в поддержку ГИС ЖКХ - сказали что неверно рассчитаны "DigestValue" - как я понимаю в <xades:CertDigest>.
Т.е. получается DigestValue рассчитан по алгоритмам не к ключу ГОСТ2012 - где то не поменял ссылки? Такое вообще может быть, т.к. ошибок при подписи не возникает. Например указываешь XmlDsigGost3410UrlObsolete вместо XmlDsigGost3410_2012_256Url с ключом 2012 года - ошибка естественно есть о том что не поддерживает.
Может немного обнаглел, но поскажете в какую сторону смотреть ошибку, которая может быть при расчете DigestValue?
example GIS ZhKKh.xml (6kb) загружен 2 раз(а). mojj zapros.xml (9kb) загружен 2 раз(а).
В целом подпись то получается как по примеру ГИС ЖКХ
Online two_oceans  
#5 Оставлено : 12 августа 2019 г. 6:10:47(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 42 раз
Поблагодарили: 146 раз в 139 постах
Автор: oleg_kashin Перейти к цитате
...Писал в поддержку ГИС ЖКХ - сказали что неверно рассчитаны "DigestValue" - как я понимаю в <xades:CertDigest>. ...Может немного обнаглел, но поскажете в какую сторону смотреть ошибку, которая может быть при расчете DigestValue? example GIS ZhKKh.xml (6kb) загружен 2 раз(а). mojj zapros.xml (9kb) загружен 2 раз(а).
В целом подпись то получается как по примеру ГИС ЖКХ
В подписи xades целых три DigestValue, какой из них не идет большой вопрос.

Файлы посмотрю, но у меня похоже подобная проблема (хотя и не с гис жкх)... SignatureValue по гост-2012 от тестовых запросов проверку проходит, а DigestValue по гост-2012 из тестовых запросов проверку не проходит. Уже и сохранял, то что идет на вычисление digest в отдельный файл, считал утилитой cpverify - совпадает с тем, что выдает моя программа и не совпадает с тем что в файле. Проверочные значения из самого гост-2012 и утилита и моя программа считает верно. Выглядит как будто текст на вычисление идет неверный.

Сверял текст на вычисление digest с тестовой программкой эксклюзивной каноникализации на .NET - текст тоже совпадает, при добавлении в архив контрольные суммы файлов с полученными фрагментами совпадают, то есть каких-то отличающихся непечатных символов нет. Загадка прям. Уже была шальная мысль текст перевернуть до полного счастья, но пока не проверял))) Остается надеяться, что совместными усилиями сдвинем вопрос с мертвой точки, так как у меня сертификат ис по гост-2001 истекает уже через неделю (внезапно).

UPD: Файл Вашего запроса посмотрел (для референсов воспользовался "эталонной" программкой эксклюзивной каноникализации на .NET) - DigestValue от декодированного из Base64 сертификата совпадает (с точностью до endian),
от второго референса совпадает (если поставить PreserveWhitespace = false и с точностью до endian), от первого референса не совпадает (брал разные варианты PreserveWhitespace и endian), SignatureValue проверку не прошло (SignatureValue скорее всего из-за того что моя программа убрала переводы строк, но не убрала пробелы в SignedInfo, "эталонной" программкой тут сложно воспользоваться, чуть позже перекомпилирую с выкидыванием пробелов и перепроверю). В целом конечно рекомендация постараться не делать отступы пробелами или табуляцией перед тегами и лишние переводы строк (если это позволит гис жкх), тогда будет без разницы значение параметра PreserveWhitespace. Вот что у меня вышло по текстам:
Про endian - я уже сам запутался какой нужен. По стадарту вроде как нужен big endian, а КриптоПро возвращает little endian. Для смены берется некодированный хэш как массив байтов и делается reverse массива, потом кодируется в base64. То есть когда все с точностью до endian будет совпадать, но гис ругаться на неверное значение, то можно еще попробовать сменить endian. А пока не совпадает переворачивать лишний раз не нужно, так как с гост-2001 же работало.

В соседней теме https://www.cryptopro.ru...&m=105596#post105596 мне посоветовали включить лог трансформов, мне совет не очень пригодился, но Вам может помочь сравнить значения текста идущего на вычисление Digest.

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

Online two_oceans  
#6 Оставлено : 13 августа 2019 г. 10:32:45(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 42 раз
Поблагодарили: 146 раз в 139 постах
По примеру получается еще интереснее, пример из первого сообщения хотя бы проходит проверку SignatureValue, в то же время в последнем Вашем сообщении приложен судя по значению подписи и значениям хэшей тот пример в виде файла, но уже с кучей табуляций и переводов строки, и проверка signatureValue уже не проходит. Поэтому желательно не копировать через буфер из какого-то просмотрщика, а записать как бинарный массив байтов в файл прямо в программе, где формируете подпись, так результат диагностики будет гораздо точнее. Аналогично с примером - желательно сохранить в точности как прислала поддержка.

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

Offline oleg_kashin  
#7 Оставлено : 13 августа 2019 г. 21:39:21(UTC)
oleg_kashin

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

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

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

В соседней теме https://www.cryptopro.ru...&m=105596#post105596 мне посоветовали включить лог трансформов, мне совет не очень пригодился, но Вам может помочь сравнить значения текста идущего на вычисление Digest.


Пошел осознавать и обдумывать, благо сертификат истекает в декабре и пока не так припекает. Кстати форматирование - все результат деятельности примера с гитхаба,т.е. выходную xml руками не форматировал ни разу, чего не скажу про пример с сайта ГИС ЖКХ - его в xml не нашел - только пример вытащил из Word документа - Альбом ТТФ (https://dom.gosuslugi.ru/filestore/publicDownloadServlet?context=contentmanagement&uid=d6555fd7-0903-4efa-9b60-d37faf1484fd&mode=view)
Кстати когда пробовал примеры из \simple\Xml\cs\SignSmevRequest.cs и SignNode.cs на выходе не форматированный xml - не оч понял откуда в примере с гита форматирование на выходе - короче с каждым разом все интереснее и интереснее)
Автор: two_oceans Перейти к цитате

(для референсов воспользовался "эталонной" программкой эксклюзивной каноникализации на .NET)

Если можно просветите побробнее что это?




Online two_oceans  
#8 Оставлено : 14 августа 2019 г. 7:13:40(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 42 раз
Поблагодарили: 146 раз в 139 постах
Автор: oleg_kashin Перейти к цитате
короче с каждым разом все интереснее и интереснее
Просто не то слово. Сейчас еще в ту тему отпишу какие фокусы выяснились со смэв 3 и гост-2012.

Автор: oleg_kashin;105836
Автор: two_oceans Перейти к цитате
(для референсов воспользовался "эталонной" Перейти к цитате
Если можно просветите побробнее что это?
Предыстория.
Вот ссылка на оригинальную тему с программой, за 2 года побочных эффектов не замечено. Я почему-то читал клон этой темы на другом форуме без сообщения с исходником, но пусть тут будет оригинальная тема https://www.cryptopro.ru....aspx?g=posts&t=8560

Замечу только, что когда делается каноникализация для ЭЦП вообще и SOAP в частности, некоторые пункты процедуры каноникализации срабатывают вхолостую, потому что стандарт ЭЦП регламентирует нормализацию переводов строк, то есть в норме на каноникализацию никогда не придет символ с кодом 13. Сам по себе стандарт xml разрешает из символов до пробела (кода 32) только переводы строк и табуляцию (коды 9,10,13) Далее стандарт Соап накладывает ограничение на инструкции обработки и внешние "ссылки на разделы", то есть они тоже не придут на каноникализацию при подписи соап запросов. Остаются только символы 9 и 10 с которыми куча проблем. Если в исходном запросе нет символов 9, 10, 13 (так как при нормализации переводов строк 13 меняется на 10), то подписание и проверка проходят гораздо проще.

Отредактировано пользователем 14 августа 2019 г. 7:51:29(UTC)  | Причина: Не указана

Offline oleg_kashin  
#9 Оставлено : 26 августа 2019 г. 17:41:11(UTC)
oleg_kashin

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

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

Сказал(а) «Спасибо»: 4 раз
вообщем да..проблема была в канонизации
В примере ГИС ЖКХ на гост2012 была XmlDsigExcC14NTransformUrl = "http://www.w3.org/2001/10/xml-exc-c14n#"
на ГОСТ2011 была XmlDsigCanonicalizationUrl = "http://www.w3.org/TR/2001/REC-xml-c14n-20010315"

В исходном примере применял как в примере ГИС ЖКХ - не проходило
поменял на XmlDsigCanonicalizationUrl как в примере на ГОСТ2001 - запрос проходит без проблем с подписью ключом по ГОСТ2012
Странно..осталось разобраться что не так с XmlDsigExcC14NTransformUrl - отпишусь.
Много времени потерял думал проблема в другом...как бы я не особо во всем этом разбираюсь

Отредактировано пользователем 26 августа 2019 г. 17:42:28(UTC)  | Причина: Не указана

Online two_oceans  
#10 Оставлено : 27 августа 2019 г. 5:04:44(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 42 раз
Поблагодарили: 146 раз в 139 постах
Автор: oleg_kashin Перейти к цитате
поменял на XmlDsigCanonicalizationUrl как в примере на ГОСТ2001 - запрос проходит без проблем с подписью ключом по ГОСТ2012
Странно..осталось разобраться что не так с XmlDsigExcC14NTransformUrl - отпишусь.
Какая фактически выполняется каноникализация - эксклюзивная или неэксклюзивная (надо найти эту строку и посмотреть, чтобы менялась соответственно указанному алгоритму).

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

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) загружен 1 раз(а).
primer 2012.xml (6kb) загружен 1 раз(а).

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

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

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

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

Сказал(а) «Спасибо»: 42 раз
Поблагодарили: 146 раз в 139 постах
Автор: 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)
Online two_oceans  
#13 Оставлено : 6 сентября 2019 г. 8:25:32(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 42 раз
Поблагодарили: 146 раз в 139 постах
По приложенным файлам: в примере у меня проходит проверка 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, который отправляет ГИС ЖКХ (собственно на нем я и пытаюсь сделать)
Не имеет проверки подписи на борту - все что я видел это проверка срока действия сертификата.
Online two_oceans  
#15 Оставлено : 6 сентября 2019 г. 11:13:09(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 42 раз
Поблагодарили: 146 раз в 139 постах
Автор: 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)  | Причина: Не указана

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

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

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

Сказал(а) «Спасибо»: 42 раз
Поблагодарили: 146 раз в 139 постах
Автор: 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) загружен 1 раз(а). Если есть возможность посмотреть - как я надеюсь беда именно со вторым референс.

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

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

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

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

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

Сказал(а) «Спасибо»: 42 раз
Поблагодарили: 146 раз в 139 постах
Автор: 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 Лента
Пользователи, просматривающие эту тему
2 Страницы12>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.