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

Уведомление

Icon
Error

16 Страницы«<1011121314>»
Опции
К последнему сообщению К первому непрочитанному
Offline ARnikev  
#111 Оставлено : 26 июня 2015 г. 14:17:30(UTC)
ARnikev

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Автор: afev Перейти к цитате
Может быть, у вас bouncycastle прописан в java.security? (выше JCP в списке провайдеров)


Да, действительно, спасибо.
Offline ARnikev  
#112 Оставлено : 26 июня 2015 г. 14:46:51(UTC)
ARnikev

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Сформировал сейчас с помощью примера GisGmpServiceLowEnvelopeExample сообщение на импорт начисления (переделал с сообщения на импорт платежа), с моими данными - проверку на тестовом сервисе подпись прошла. Но тут все неймспейсы руками проставляются, остается вопрос как сделать корректное сообщение из классов, получаемых из wsdl.

п.с. до этого попробовал сформировать и подписать ссобщение примером GisGmpServiceCombinedExample, т.е. из java классов, подправив его для импорта начисления - ответ сервиса был, что подпись под сущностью некорректна.
Offline ARnikev  
#113 Оставлено : 26 июня 2015 г. 15:18:21(UTC)
ARnikev

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Есть люди, которым удалось корректно подписать сообщение, сформированное из классов, полученных из wsdl сервиса? Хоть одному это удалось сделать?
Offline Евгений Афанасьев  
#114 Оставлено : 26 июня 2015 г. 15:37:56(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,910
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
Предположительно, eagames-ru и Inviz.
Offline ARnikev  
#115 Оставлено : 26 июня 2015 г. 15:47:48(UTC)
ARnikev

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Автор: afev Перейти к цитате
Предположительно, eagames-ru и Inviz.


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

Если честно не понимаю, как расположение неймспейсов на хэш сущности повлиять может. Точнее он влияет конечно, но мы же неймспейсы не меняем после подписи сущности, они остаются какими и были. Посчитали хэш по сущности, записали его в DigestValue, потом элемент сущности вообще никак не меняется Brick wall .

Отредактировано пользователем 26 июня 2015 г. 15:49:11(UTC)  | Причина: Не указана

Offline belgampaul  
#116 Оставлено : 26 июня 2015 г. 19:08:45(UTC)
belgampaul

Статус: Новичок

Группы: Участники
Зарегистрирован: 25.06.2015(UTC)
Сообщений: 8

Поблагодарили: 2 раз в 1 постах
Автор: ARnikev Перейти к цитате
Автор: 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 видно, что в пакете неймспейсы объявлены и на уровне сущности. Но в примере, где только сущность, неймспейсов больше.

В ЕТК приняли заявку, но ответ неизвестно когда будет, а вопрос еще вчера вечером отправил. Все что пока есть это ими расчитанный хэш, но на основании каких данных рассчитан не упомянули.



Да, мне тоже только хэш прислали и все)).


Все выяснили наконец-то. Службе поддержки как обычно незачет. 2 дня ждать от них ответ, чтобы они еще раз прислали DigestValue, а не сущность, которую проверяли.
Обошлись без службы поддержки. Подписываемая сущность у нас верная. Точнее Digest ее верен. Но подписываем мы не одновременно с отправлением. Сначала подписываем. Потом на другом статусе документ выгружаем. А JAXB, если его не научить, каждый раз может новые префиксы придумывать. В итоге получается картина, что Digest верный для нас, но данные изменились.

В итоге: и сущность, которую подписываем и сущность, которую передаем в soap пакете должны быть идентичны.

Offline ARnikev  
#117 Оставлено : 29 июня 2015 г. 9:21:04(UTC)
ARnikev

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Автор: belgampaul Перейти к цитате

Все выяснили наконец-то. Службе поддержки как обычно незачет. 2 дня ждать от них ответ, чтобы они еще раз прислали DigestValue, а не сущность, которую проверяли.
Обошлись без службы поддержки. Подписываемая сущность у нас верная. Точнее Digest ее верен. Но подписываем мы не одновременно с отправлением. Сначала подписываем. Потом на другом статусе документ выгружаем. А JAXB, если его не научить, каждый раз может новые префиксы придумывать. В итоге получается картина, что Digest верный для нас, но данные изменились.

В итоге: и сущность, которую подписываем и сущность, которую передаем в soap пакете должны быть идентичны.


Что значит на другом статусе документ выгружаете? Вы убедились что ошибка в этом, удалось в итоге импортировать что-то корректно на тестовый сервис?
Я только что проверил у себя, у меня все префиксы и сущность в целом остается неизменной, что до подписи, что после, что перед самой отправкой сообщения в ГИС ГМП...

Offline ARnikev  
#118 Оставлено : 29 июня 2015 г. 12:53:34(UTC)
ARnikev

Статус: Активный участник

Группы: Участники
Зарегистрирован: 16.10.2013(UTC)
Сообщений: 56

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Только что сформировал 2 запроса с абсолютно одинаковыми сущностями Charge, о чем говорит одинаковое значение DigestValue в теге подписи. Один запрос сформировал примером GisGmpServiceLowEnvelopeExample, который выложен на главной (https://www.cryptopro.ru/blog/2015/06/22/sozdanie-podpisi-xades-t-dlya-vzaimodeistviya-s-gis-gmp-po-spetsifikatsii-versii-116), второй сформировал примером GisGmpServiceCombinedExample. В итоге запрос сформированный руками ГИС ГМП схвал, а запрос сформированный из классов, полученных с wsdl сервиса - не схавал, ответ был "ЭП по сущностью не верна".

Какой-то бред не правда ли?Brick wall Написал вопрос в саппорт ГИС ГМП, придется опять кучу времени ждать ответа.

пс. запросы можно тут посмотреть https://dropmefiles.com/rZswb
Offline belgampaul  
#119 Оставлено : 29 июня 2015 г. 13:02:39(UTC)
belgampaul

Статус: Новичок

Группы: Участники
Зарегистрирован: 25.06.2015(UTC)
Сообщений: 8

Поблагодарили: 2 раз в 1 постах
Автор: ARnikev Перейти к цитате
Автор: belgampaul Перейти к цитате

Все выяснили наконец-то. Службе поддержки как обычно незачет. 2 дня ждать от них ответ, чтобы они еще раз прислали DigestValue, а не сущность, которую проверяли.
Обошлись без службы поддержки. Подписываемая сущность у нас верная. Точнее Digest ее верен. Но подписываем мы не одновременно с отправлением. Сначала подписываем. Потом на другом статусе документ выгружаем. А JAXB, если его не научить, каждый раз может новые префиксы придумывать. В итоге получается картина, что Digest верный для нас, но данные изменились.

В итоге: и сущность, которую подписываем и сущность, которую передаем в soap пакете должны быть идентичны.


Что значит на другом статусе документ выгружаете? Вы убедились что ошибка в этом, удалось в итоге импортировать что-то корректно на тестовый сервис?
Я только что проверил у себя, у меня все префиксы и сущность в целом остается неизменной, что до подписи, что после, что перед самой отправкой сообщения в ГИС ГМП...


>>Что значит на другом статусе документ выгружаете?
Это значит, что сущность подписывается на одном статусе, а пакет отправляется на другом. В пакете раньше пространства имен в сущности могли отличаться от тех, что были использованы при подписании, т.к. jaxb по-умолчанию сам выбирает префиксы.

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

Offline Bpar  
#120 Оставлено : 30 июня 2015 г. 10:43:29(UTC)
Bpar

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

Группы: Участники
Зарегистрирован: 05.08.2014(UTC)
Сообщений: 12

Поблагодарили: 2 раз в 2 постах
Еще офтоп

Автор: Inviz Перейти к цитате

Я добавил еще один импорт в типы и все сгенирилось через wsimport нормально

<wsdl:types>
<xsd:schema targetNamespace="http://roskazna.ru/gisgmp/02000000/SmevGISGMPService/" xmlns:smev="http://smev.gosuslugi.ru/rev120315">
<xsd:import schemaLocation="xsd/request/smev.unifo.rev120315.xsd" namespace="http://smev.gosuslugi.ru/rev120315"/>
<xsd:import schemaLocation="xsd/request/Message.xsd" namespace="http://roskazna.ru/gisgmp/xsd/116/Message"/>
<xsd:element name="GISGMPTransferMsg" type="smev:BaseMessageType"/>
</xsd:schema>
</wsdl:types>



При попытке импорта xsd схем выдается ошибка

wsdl.exe /language:cs SmevGISGMPService.wsdl
Ошибка. Не удается импортировать привязку "SmevGISGMPServiceSOAP" из пространства имен "http://roskazna.ru/gisgmp/0
2000000/SmevGISGMPService/".
- Не удается импортировать операцию "GISGMPTransferMsg".
- Отсутствует тип данных "http://smev.gosuslugi.ru/rev120315:BaseMessageType".

Архив со схемами распакован в тот-же каталог с сохранением иерархии каталогов.
Что делать, подскажите.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
16 Страницы«<1011121314>»
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.