Автор: Infopol 
А какой третий параметр?Вроде по TLB 2 параметра.
Похоже про разное говорим.
Автор: Infopol Вот как я делаю... 1.Этап считывание XML
А по 2 наклонные черты в значениях xmlns где потерялись?
Автор: Infopol 2.Далее считываю два варианта для вычисления DigestValue
2.1 Body
Нет 2 наклонных черт, лишний пробел в начале, приведенный хэш длиной ~90 символов base64 - это слишком много для гост-2012 256 бит, надо в 2 раза короче. Сравните:
Код:<soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><ns:SendGetBatchRequest xmlns:ns="urn://xsd.dmdk.goznak.ru/exchange/1.0"><ns:CallerSignature></ns:CallerSignature><ns:RequestData id="body"><ns:UIN_INP>1111111111111111</ns:UIN_INP></ns:RequestData></ns:SendGetBatchRequest></soapenv:Body>
6ACD785A651B72715837AB1B554BCDB9472F83D90A134FED858E4891B7D689AB
as14WmUbcnFYN6sbVUvNuUcvg9kKE0/thY5IkbfWias=
FLIP RESULT:
AB89D6B791488E85ED4F130AD9832F47B9CD4B551BAB375871721B655A78CD6A
q4nWt5FIjoXtTxMK2YMvR7nNS1UbqzdYcXIbZVp4zWo=
Автор: Infopol 2.2 RequestData
Не то пространство имен, нет 2 наклонных черт, слишком длинный хэш. Сравните:
Код:<ns:RequestData xmlns:ns="urn://xsd.dmdk.goznak.ru/exchange/1.0" id="body"><ns:UIN_INP>1111111111111111</ns:UIN_INP></ns:RequestData>
DDB6B484B1FB54113EDF0B73A0E7742CC645E6FF2B628A138654DFF18F90464B
3ba0hLH7VBE+3wtzoOd0LMZF5v8rYooThlTf8Y+QRks=
FLIP RESULT:
4B46908FF1DF5486138A622BFFE645C62C74E7A0730BDF3E1154FBB184B4B6DD
S0aQj/HfVIYTimIr/+ZFxix056BzC98+EVT7sYS0tt0=
Автор: Infopol 3. Формирую секцию SignedInfo
По вашей рекомендации использую xэш от RequestData
желательно без переводов строк, нет трансформов? Если делали приведение к каноничному виду (или подпись будет вложена в подписанный фрагмент) трансформ обязательно надо указывать.
Слишком длинный хэш, нет 2 наклонных черт, нет xmlns:ds="...". Нюанс в том, что ds:CanonicalizationMethod Algorithm применяется к содержимому SignedInfo и при этом в каноничном виде появляется xmlns:ds="http://www.w3.org/2000/09/xmldsig#". Сравните:
Код:<ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256"/>
<ds:Reference URI="#body">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"/>
<ds:DigestValue>3ba0hLH7VBE+3wtzoOd0LMZF5v8rYooThlTf8Y+QRks=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
Автор: Infopol 4. Подписываю именно эту секцию ... ds:SignatureValue очень длинный, может нужен Hash от этой строки?
На этом месте стоп, совсем не в ту сторону - в SignatureValue указывается "голое"/"чистое"/RAW значение подписи, для гост оно должно быть длиной в 2 раза больше чем хэш, то есть для гост-2012 256 = 84-90 символов base64. 90 если с переводом строки, 88 без перевода строки (84-86 крайне редкий случай). SignedData формирует полноценную подпись cades, вырезать оттуда нужное "чистое" значение проблематично (место может сдвигаться, для точного места надо все раскодировать) и не всегда возможно (в продвинутых форматах cades подписывается не сам текст). Для таких случаев есть отдельный объект RawSignature, дающий "чистое" значение и нужную длину. Подробнее:
4.1 создать HashedData, RawSignature, Signer
4.2 указать HashedData.Encoding= base64
4.3 закодировать SignedInfo в base64 (без 4.2-4.3 связка передача в плагин может портить данные, перестраховка)
4.4 загрузить кодированную SignedInfo в объект HashedData.Content (собственно если после пунктов 4.1-4.4 получить значение хэша, так можно считать хэш для 2.1, 2.2)
4.5 потом передать объект HashedData в RawSignature.SignHash (еще там насколько помню нужен Signer с указанным сертификатом)
4.6 полученное из SignHash значение скорее всего нужно перевернуть (первый байт с последним, второй с предпоследним и т.д.)
4.7 закодировать в Base64
4.8 вставить в SignatureValue
