Статус: Новичок
Группы: Участники
Зарегистрирован: 25.06.2015(UTC)
Сообщений: 8
Поблагодарили: 2 раз в 1 постах
|
Автор: ARnikev  Цитата:
Абсолютно идентичная картина. Хэшируется локально одна xml (байты взятые из строки, представляющую собой xml фрагмент. Что происходит при проверке и какую xml ГИС ГМП хэширует пока не 100% ясно. Ясно,что хэшируется что-то другое.
Пока жду ответа от службы поддержки ЕТК, может кто-то выложить xml подписываемой сущности?
У моих сущностей есть префикс и namespace указан для этого префикса в корневом элементе сущности. А в soap-пакете namespace, используемый сущностями (FinalPayment, Charge), указан в тэге RequestMessage.
На форматах 1.15.0 xml был одинаков везде (в soap-пакете и в сущности). Там нигде не было неймспейсов.
Выше я выкладывал свой подписанный запрос на импорт начисления. upd. Кстати тоже думаю, что дело как-то касается неймспейсов. Выяснил, что старая подпись XMLDsig тоже перестала работать с сообщением нового формата. Так и не могу понять почему, элемент сущности после ее подписи и после подписи всего сообщения визуально выглядит одинаково. Но при проверке подписи сущности финального документа DigestValue получается совсем другим. Проблема в том, что я неймспейсы руками не проставляю даже, они маршалятся из java классов, которые я с wsdl сервиса получил. Да, видел примеры. В том-то и проблема, что у Вас как и у меня проблема похожая. В найденных примерах по этой ссылке http://bankir.ru/dom/thr...p;viewfull=1#post3251458 видно, что в пакете неймспейсы объявлены и на уровне сущности. Но в примере, где только сущность, неймспейсов больше. В ЕТК приняли заявку, но ответ неизвестно когда будет, а вопрос еще вчера вечером отправил. Все что пока есть это ими расчитанный хэш, но на основании каких данных рассчитан не упомянули.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Автор: belgampaul Автор: ARnikev Цитата:
Абсолютно идентичная картина. Хэшируется локально одна xml (байты взятые из строки, представляющую собой xml фрагмент. Что происходит при проверке и какую xml ГИС ГМП хэширует пока не 100% ясно. Ясно,что хэшируется что-то другое.
Пока жду ответа от службы поддержки ЕТК, может кто-то выложить xml подписываемой сущности?
У моих сущностей есть префикс и namespace указан для этого префикса в корневом элементе сущности. А в soap-пакете namespace, используемый сущностями (FinalPayment, Charge), указан в тэге RequestMessage.
На форматах 1.15.0 xml был одинаков везде (в soap-пакете и в сущности). Там нигде не было неймспейсов.
Выше я выкладывал свой подписанный запрос на импорт начисления. upd. Кстати тоже думаю, что дело как-то касается неймспейсов. Выяснил, что старая подпись XMLDsig тоже перестала работать с сообщением нового формата. Так и не могу понять почему, элемент сущности после ее подписи и после подписи всего сообщения визуально выглядит одинаково. Но при проверке подписи сущности финального документа DigestValue получается совсем другим. Проблема в том, что я неймспейсы руками не проставляю даже, они маршалятся из java классов, которые я с wsdl сервиса получил. Да, видел примеры. В том-то и проблема, что у Вас как и у меня проблема похожая. В найденных примерах по этой ссылке http://bankir.ru/dom/thr...p;viewfull=1#post3251458 видно, что в пакете неймспейсы объявлены и на уровне сущности. Но в примере, где только сущность, неймспейсов больше. В ЕТК приняли заявку, но ответ неизвестно когда будет, а вопрос еще вчера вечером отправил. Все что пока есть это ими расчитанный хэш, но на основании каких данных рассчитан не упомянули. Да, мне тоже только хэш прислали и все)).
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Еще я заметил, что в эталонных примерах, которые выкладывают тут - bankri.ru в элементе Reference подписи сущности присутствуют 2 элемента TRansform: Код:
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411"/>
<ds:Reference URI="">
<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="http://www.w3.org/2001/04/xmldsig-more#gostr3411"/>
<ds:DigestValue>D8PKju/BI+j0+fR5YHhlBPU+WYmetQRvJ+Wcg1uf/vc=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
А при формировании подписи примером, предложенным avef, присутствует только 1 элемент: Код:
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411"/>
<ds:Reference Id="xmldsig-e3bd6150-4f0b-4f24-a337-729754e755ac-ref0" URI="#A_e9cc729d-a8ec-4288-97ab-f6437295d494">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411"/>
<ds:DigestValue>3DuYKKIFeMHkA9ZjwGn62rRPtEqbIQML6IYc5nWgoyA=</ds:DigestValue>
</ds:Reference>
<ds:Reference Type="http://uri.etsi.org/01903#SignedProperties" URI="#xmldsig-e3bd6150-4f0b-4f24-a337-729754e755ac-signedprops">
<ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411"/>
<ds:DigestValue>/n8kB2j1aG9fc2fTHZKWs25its9x2I6ldz4iUB+uStc=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
То есть отсутствует алгоритм каноникализации подписываемой сущности. А по стандарту Xades каноникализация сущности должна выполняться перед вычислением ее хэша. Это ошибка или я что-то не так понимаю?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963  Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
|
Тогда можно добавить: Код:
final DataObjectDesc dataObj = new DataObjectReference(referenceURI);
dataObj.withTransform(new EnvelopedSignatureTransform());
dataObj.withTransform(new ExclusiveCanonicalXMLWithoutComments()); // !
|
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Автор: afev Тогда можно добавить: Код:
final DataObjectDesc dataObj = new DataObjectReference(referenceURI);
dataObj.withTransform(new EnvelopedSignatureTransform());
dataObj.withTransform(new ExclusiveCanonicalXMLWithoutComments()); // !
Да, сделал уже, результат все тот же). Уже не знаю в какую сторону смотреть  .
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
|
|
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Автор: afev Спасибо, посмотрю, только мне интересен как раз вот этот пример: Цитата:
Другой пример, GisGmpServiceCombinedExample, похож на GisGmpServiceExample, но формирование документа происходит прямо в коде с помощью классов, созданных по xsd-схемам, взятым из архива, вложенного в спецификацию форматов ГИС ГМП.
Таким образом сформированные сообщения вы тоже проверяли, сервис ГИС ГМП на подпись не ругается?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
|
Мы получали разные ошибки, не было ни одного успешного импорта (0), т.к. мы не зарегистрированы в системе. Были ошибки как 5, 8, так и 13 (неверная ЭП). Но неизвестно, проверялась ли внутренняя подпись в тех случаях, когда выполнялась некая проверка, возвращающая 5 или 8 (неизвестна очередность "проверка"-"код обработки"). Другие пользователи форума сообщали об успешных импортах. P.S. Попробуйте подставить свои значения для начала, например, в GisGmpServiceLowEnvelopeExample. Отредактировано пользователем 26 июня 2015 г. 10:44:15(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56
Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
|
Автор: afev Мы получали разные ошибки, не было ни одного успешного импорта (0), т.к. мы не зарегистрированы в системе. Были ошибки как 5, 8, так и 13 (неверная ЭП). Но неизвестно, проверялась ли внутренняя подпись в тех случаях, когда выполнялась некая проверка, возвращающая 5 или 8 (неизвестна очередность "проверка"-"код обработки"). Другие пользователи форума сообщали об успешных импортах.
P.S. Попробуйте подставить свои значения для начала, например, в GisGmpServiceLowEnvelopeExample. Пробую сейчас подписать сообщение вашим примером GisGmpServiceLowEnvelopeExample. Почему-то когда пробую подписать вашим примером, из моего сертификата получается public key типа class org.bouncycastle.jcajce.provider.asymmetric.ecgost.BCECGOST3410PublicKey вместо ru.CryptoPro.JCP.Key.GostPublicKey и алгоритм ECGOST3410 вместо GOST3410EL. Соответственно падает Exception в недрах xmlsec-1.5.0 при попытки взять алгоритм подпись по URI: Код:
private static SignatureAlgorithmSpi getSignatureAlgorithmSpi(String algorithmURI)
throws XMLSignatureException {
try {
Class<? extends SignatureAlgorithmSpi> implementingClass =
algorithmHash.get(algorithmURI);
if (log.isDebugEnabled()) {
log.debug("Create URI \"" + algorithmURI + "\" class \""
+ implementingClass + "\"");
}
return implementingClass.newInstance();
} catch (IllegalAccessException ex) {
Object exArgs[] = { algorithmURI, ex.getMessage() };
throw new XMLSignatureException("algorithms.NoSuchAlgorithm", exArgs, ex);
} catch (InstantiationException ex) {
Object exArgs[] = { algorithmURI, ex.getMessage() };
throw new XMLSignatureException("algorithms.NoSuchAlgorithm", exArgs, ex);
} catch (NullPointerException ex) {
Object exArgs[] = { algorithmURI, ex.getMessage() };
throw new XMLSignatureException("algorithms.NoSuchAlgorithm", exArgs, ex);
}
Т.е. не может найти алгоритм для URI ECGOST3410. Подскажите, пожалуйста в чем может быть проблема.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
|
Может быть, у вас bouncycastle прописан в java.security? (выше JCP в списке провайдеров) |
|
 1 пользователь поблагодарил Евгений Афанасьев за этот пост.
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
