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

Уведомление

Icon
Error

8 Страницы«<45678>
Опции
К последнему сообщению К первому непрочитанному
Offline belgampaul  
#101 Оставлено : 25 июня 2015 г. 19:29:29(UTC)
belgampaul

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

Группы: Участники
Зарегистрирован: 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 видно, что в пакете неймспейсы объявлены и на уровне сущности. Но в примере, где только сущность, неймспейсов больше.

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

Offline ARnikev  
#102 Оставлено : 25 июня 2015 г. 20:00:35(UTC)
ARnikev

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

Группы: Участники
Зарегистрирован: 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 видно, что в пакете неймспейсы объявлены и на уровне сущности. Но в примере, где только сущность, неймспейсов больше.

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



Да, мне тоже только хэш прислали и все)).
Offline ARnikev  
#103 Оставлено : 26 июня 2015 г. 10:00:16(UTC)
ARnikev

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

Группы: Участники
Зарегистрирован: 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 каноникализация сущности должна выполняться перед вычислением ее хэша. Это ошибка или я что-то не так понимаю?
Offline Евгений Афанасьев  
#104 Оставлено : 26 июня 2015 г. 10:17:47(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 16 раз
Поблагодарили: 550 раз в 525 постах
Тогда можно добавить:
Код:

final DataObjectDesc dataObj = new DataObjectReference(referenceURI);
dataObj.withTransform(new EnvelopedSignatureTransform());
dataObj.withTransform(new ExclusiveCanonicalXMLWithoutComments()); // !
Offline ARnikev  
#105 Оставлено : 26 июня 2015 г. 10:24:02(UTC)
ARnikev

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Автор: afev Перейти к цитате
Тогда можно добавить:
Код:

final DataObjectDesc dataObj = new DataObjectReference(referenceURI);
dataObj.withTransform(new EnvelopedSignatureTransform());
dataObj.withTransform(new ExclusiveCanonicalXMLWithoutComments()); // !


Да, сделал уже, результат все тот же). Уже не знаю в какую сторону смотреть Brick wall .
Offline Евгений Афанасьев  
#106 Оставлено : 26 июня 2015 г. 10:29:07(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 16 раз
Поблагодарили: 550 раз в 525 постах
Посмотрите еще раз https://www.cryptopro.ru...petsifikatsii-versii-116
В архиве есть несколько примеров (пакет xades.gisgmp), в частности, посмотрите те, где из кусков собирается документ.
Offline ARnikev  
#107 Оставлено : 26 июня 2015 г. 10:36:29(UTC)
ARnikev

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 2 раз в 1 постах
Автор: afev Перейти к цитате
Посмотрите еще раз https://www.cryptopro.ru...petsifikatsii-versii-116
В архиве есть несколько примеров (пакет xades.gisgmp), в частности, посмотрите те, где из кусков собирается документ.


Спасибо, посмотрю, только мне интересен как раз вот этот пример:
Цитата:

Другой пример, GisGmpServiceCombinedExample, похож на GisGmpServiceExample, но формирование документа происходит прямо в коде с помощью классов, созданных по xsd-схемам, взятым из архива, вложенного в спецификацию форматов ГИС ГМП.


Таким образом сформированные сообщения вы тоже проверяли, сервис ГИС ГМП на подпись не ругается?
Offline Евгений Афанасьев  
#108 Оставлено : 26 июня 2015 г. 10:42:05(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 16 раз
Поблагодарили: 550 раз в 525 постах
Мы получали разные ошибки, не было ни одного успешного импорта (0), т.к. мы не зарегистрированы в системе. Были ошибки как 5, 8, так и 13 (неверная ЭП). Но неизвестно, проверялась ли внутренняя подпись в тех случаях, когда выполнялась некая проверка, возвращающая 5 или 8 (неизвестна очередность "проверка"-"код обработки"). Другие пользователи форума сообщали об успешных импортах.

P.S. Попробуйте подставить свои значения для начала, например, в GisGmpServiceLowEnvelopeExample.

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

Offline ARnikev  
#109 Оставлено : 26 июня 2015 г. 14:00:18(UTC)
ARnikev

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

Группы: Участники
Зарегистрирован: 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. Подскажите, пожалуйста в чем может быть проблема.
Offline Евгений Афанасьев  
#110 Оставлено : 26 июня 2015 г. 14:05:06(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 16 раз
Поблагодарили: 550 раз в 525 постах
Может быть, у вас bouncycastle прописан в java.security? (выше JCP в списке провайдеров)
thanks 1 пользователь поблагодарил Евгений Афанасьев за этот пост.
ARnikev оставлено 26.06.2015(UTC)
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,360
Российская Федерация
Откуда: Крипто-Про

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