Предлагаю начать с проверки заготовленного подписываемого xml документа - в нем не должно быть повторяющихся аттрибутов Id, аттрибуты URI должны указывать на соответствующие Id существующих нужных элементов. Если документ неверный, но даже правильный код будет выдавать ЭП с ошибкой, просто потому что в код не заложено автоматическое исправление ошибок самого подписываемого документа.

Например, в соседней теме из-за двойного Id выбирался Id на заготовку тега для сертификата, соответственно заготовка подписывалась, потом в нее добавлялся сертификат, что приводило к ошибке проверки подписи потому что к моменту проверки подписанный тег фактически изменился вставкой сертификата. Мало того, значение хэша в референсе оказывалось независимым ни от "полезных данных" документа, ни от сертификата. И все из-за того, что Id "полезных данных" совпал c Id заготовки под сертификат и заготовка шла в документе первой.
Точно так же если Вы укажете несуществующий в документе Id для указания подписываемого узла, то скорее всего подпишется пустая строка и хэш будет независим ни от чего.

Еще одной частой ошибкой является использование неправильного метода приведения к каноническому виду. Указали "обычный" c14n вместо эксклюзивного c14n и вот уже сообщение об ошибке проверки ЭП.

Добавлю, что автоматическое исправление по стандарту также нежелательно, так как некоторые информационные системы участников принимают аттрибуты в строго фиксированном порядке, при автоисправлении порядок может измениться. Просто проверьте взглядом подписываемые документы на соответствие здравому смыслу.

Отредактировано пользователем 22 октября 2018 г. 6:12:02(UTC)  | Причина: Не указана

Имеется библиотека XADES и
2 программы под СМЭВ2 и под СМЭВ3
Функции подписи сущностей и конвертов
Текстуально одинаковы.
Для СМЭВ2 все прекрасно работает.
А вот для СМЭВ3 - сущности подписываются,
а вот конверт выдает исключение и что делать опять не знаю.

2018.10.24 23:18:13: Подписываем запрос.
2018.10.24 23:23:40: Адресат вызова создал исключение.StackTrace
в System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
в System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
в System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
в System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
в Microsoft.Xades.XadesSignedXml.BuildDigestedReferences() в D:\ovi\Library\XadesSignedXml.cs:строка 1484
в Microsoft.Xades.XadesSignedXml.ComputeSignature() в D:\ovi\Library\XadesSignedXml.cs:строка 1374
в bx_smev3.SignSmevRequest.SignXmlTransport(XmlDocument doc, X509Certificate2 Certificate) в D:\ovi\Smev_bx3\SignSmevRequest.cs:строка 116
в bx_smev3.xUtil.prepareXmlRequest() в D:\ovi\Smev_bx3\XmlUtil.cs:строка 241
в bx_smev3.Program.Main(String[] args) в D:\ovi\Smev_bx3\Program.cs:строка 97
2018.10.24 23:23:40: Err=21 в SignSmevRequest.SignXmlTransport

Если не найдено ни одного элемента reference, то похоже поиск того, что собрали - в итоге не удался.

Судя по примерам кода - многие разработчики ищут нужные места документа таким образом, который чудом срабатывает только в частном случае и получают проблемы, когда структура документа меняется. Писать для частного случая в принципе нормально, но важно провести исследование и оставлять комментарии в каких случаях работает, в каких нет.

Чтобы было более предметно, покажите пожалуйста xml, который передаете на подпись (можно не разбавлять переносами и отступами, в одну строчку) и уточните как именно ищите место прикрепления подписи, какой id подписываемого элемента указываете.

Если правильно понимаю, это сообщение для ГИС ГМП об уплате? Тогда я даже не знаю с чего начать - по требованиям СМЭВ 3 вид сведений и информационная система поставщика (ГИС ГМП) распознается по пространству имен и имени тега стоящего непосредствеенно под тегом MessagePrimaryContent, причем должен быть только один непосредственный потомок (корневой тег вида сведений) у MessagePrimaryContent.

В приведенном тексте корневой тег вида сведений ImportPaymentsRequest (в котором в частности указывается senderIdentifier и senderRole) пропущен. В расширенном формате подписи серийный номер сертификата указывается в десятичном представлении, CertDigest SHA1 выглядит подозрительно. Для второго референса с расширенными свойствами подписи вроде как нет нужды в трансформе enveloped signature, так как свойства уже внутри подписи и в самих свойствах подписи нет. Про гост-2012 была новость о поддержке в тестовом контуре, не видел новости о продуктивном контуре.

Непосредственно после (на одном уровне? среди потомков? просто по тексту документа?) Может быть там CallerInformationSystemSignature между тегом и подписью мешает? Внутренее содержимое вообще подписано enveloped signature, то есть безразлично что нашлось подпись включена внутрь пописываемого тега. "ADE247F0FF62502C915FA6C5DA9343429BD5DE5F" что за значение?

Ну вот вроде все построилось
Подписывал через простую SignedXml
Результат, GetXml, переносил в
ns2:CallerInformationSystemSignature
ручками. Там в шаблоне была готовая структура подписи.
переносил:
ds:DigestValue
ds:SignatureValue
ds:X509Certificate

Результат с портала:
ЭП-ОВ не соответствует подписанным данным:
Ошибка проверки ЭП: Нарушена целостность ЭП.

RequestUTF8.xml (12kb) загружен 17 раз(а).

Может кто подскажет что у меня не так?

Проверка на портале GosUslugi:
Есть URL=https://smev3.gosuslugi.ru/portal/checkxmlform.jsp
Все красиво. НО на мой файл отвечает
"Ошибка разбора XML: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 841; Element type "pkg:ImportedPayment" must be followed by either attribute specifications, ">" or "/>".
"
Это полный бред.
Попросил друга, он от себя загрузил и получил результат как на портале.
Может у меня провайдер, Теле2, дурит. Не знаю.