|
legioner052019 |
|
|
Статус: Активный участник Группы: Участники
|
Добрый день. Подписываю запрос в ГИС ЖКХ используя пример jcp XAdESExample.java Код:
Получаю вот такой xml Код:
Требования ГИС ЖКХ выполняются Тех поддержка ответила: подпись запроса не верна: неверно рассчитано значение «DigestValue» . Хотел спросить в правильности реализации функции подписания. Может что то я упустил Отредактировано пользователем 15 июля 2019 г. 15:07:58(UTC) |
![]() |
|
|
two_oceans |
|
|
Статус: Эксперт Группы: Участники Сказал(а) «Спасибо»: 110 раз |
На вид полученный файл кажется нормальным. Немного подозрительно, что Signature выделен переводами строк и пробелами. К сожалению, в таком виде (с неполным сертификатом и неполным штампом времени) его проверить не представляется возможным (максимум посчитать хэш в референсах). Да и то, про второй референс не уточнено как привести к каноничному виду. Для проверки желательно прикрепить файлом. |
![]() |
|
|
legioner052019 |
|
|
Статус: Активный участник Группы: Участники
|
Автор: two_oceans На вид полученный файл кажется нормальным. Немного подозрительно, что Signature выделен переводами строк и пробелами. К сожалению, в таком виде (с неполным сертификатом и неполным штампом времени) его проверить не представляется возможным (максимум посчитать хэш в референсах). Да и то, про второй референс не уточнено как привести к каноничному виду. Для проверки желательно прикрепить файлом. Для удобства сократил. вот сам файл Код:
Цитата: Немного подозрительно, что Signature выделен переводами строк и пробелами вот пока читаю как это исправить. Отредактировано пользователем 16 июля 2019 г. 8:17:07(UTC) |
![]() |
|
|
legioner052019 |
|
|
Статус: Активный участник Группы: Участники
|
Полученный мной ранее xml файл Код:
пытаюсь проверить Код:
Возвращается ошибка xades4j.verification.QualifyingPropertiesIncorporationException: The referenced SignedProperties are not contained by the proper QualifyingProperties element Код:
В чем может быть причина? Отредактировано пользователем 17 июля 2019 г. 12:01:07(UTC) |
![]() |
|
|
two_oceans |
|
|
Статус: Эксперт Группы: Участники Сказал(а) «Спасибо»: 110 раз |
На вид все в порядке, хотя не раскодированы ИНН ОГРН (что ожидаемо), email (что немного странно). В чем смысл «proper QualifyingProperties element» пока не понял, вроде бы цель QualifyingProperties указывает на тег подписи. В моей программе SignatureValue успешно проверилось, а вот с хэшами от референсов вышло расхождение, проверка самого расширения у меня xades не допилена. |
![]() |
|
|
legioner052019 |
|
|
Статус: Активный участник Группы: Участники
|
Автор: two_oceans На вид все в порядке, хотя не раскодированы ИНН ОГРН (что ожидаемо), email (что немного странно). В чем смысл «proper QualifyingProperties element» пока не понял, вроде бы цель QualifyingProperties указывает на тег подписи. В моей программе SignatureValue успешно проверилось, а вот с хэшами от референсов вышло расхождение, проверка самого расширения у меня xades не допилена. Разобрался. Я использую spring + jaxb для работы с ГИС ЖКХ. После подписания xml изменялся. Попробовал отправить xml сразу после подписания — все ок. Спасибо two_oceans |
![]() |
|
| Пользователи, просматривающие эту тему |
|
Guest |
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Ага, уже яснее. Как бы да, не может найти, но вопрос «где ищет?» Кажется, до поиска в базе ГИС дело не доходит, дальше в середине ошибка повторяется в «…verifyEnveloped», который, насколько могу предположить по названию, проверяет структуру самой подписи XMLDSIG. Давненько не смотрел структуру: xades:SigningCertificate это я насколько помню, тег в котором пишется хэш и что-то еще из сертификата и он ссылается на данные сертификата внутри ds:KeyInfo?
Если да, то самописная программа каждый раз хэш вычисляет по сертификату и свойства сертификата читает или читает из какого-то другого файла-кэша? Есть вероятность, что испортились данные в таком кэше со свойствами сертификата (либо сам сертификат, но это маловероятно) и теперь сертификат в ds:KeyInfo не соответствует хэшу в xades:SigningCertificate.
Что-то мне кажется ошибка где-то тут, посмотрите не изменялся ли кэш. Если сохранились запросы которые уходили нормально еще можно с ними сверить содержание ds:KeyInfo и xades:SigningCertificate какие были и какие сейчас.
Отправлено спустя 7 минуты 18 секунды:
| Цитата |
|---|
| ЧЕРЕМУШКИ пишет: у меня то же самое на арбитр.ру |
Давненько там не был, но там подпись была вообще другого типа — cades, а не xades. Так что проблема явно другая. И начать нужно с «обновление чего было 06.06.2017?» ![]()
|
Grandma$ter |
|
|
Статус: Новичок Группы: Участники
|
Добрый день. Было: Новая релизация: Проверяли работу новой реализации на тестовом стенде ГИС ЖКХ — нареканий нет. Пример старого запроса: Код:
Пример нового запроса: Код:
Как видно, есть отличия. |
![]() |
|
| Пользователи, просматривающие эту тему |
|
Guest |
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Обработка иллюстрирует возможность подписания XML SOAP-конверта по стандарту Cades-BES средствами 1С с помощью внешней компоненты КриптоПРО «CAdESCOM» с учетом ГОСТ 2001 и ГОСТ 2012. Стандарт используется в различных механизмах государственных сайтов России, в том числе в СМЭВ и ГИС ЖКХ. Код не привязан к прикладному решению может быть встроен куда угодно, но только на платформе Windows.
Для работы с ГИС ЖКХ из 1С через API понадобилось выполнять цифровую подпись. Поначалу использовался OpenSSL + Python вот отсюда. Там сама подпись и контрольные суммы генерируются с помощью OpenSSL, а скрипт вставляет в исходный XML необходимые узлы.
Во-первых, все это работает через консоль, что не очень быстро. Во-вторых, OpenSSL принимает закрытый ключ в открытом PEM формате, что само по себе безобразие. В-третьих, с переходом на ГОСТ 2012 все это стало невозможно, поскольку инструментов извлечения закрытого ключа в формате PEM из сертификата, выполненного по ГОСТ 2012 не нашлось.
Штатный менеджер криптографии 1С помочь не может, так как подписывать XML не умеет, может только вернуть подпись для потока данных в формате CMS (базируется на PKCS#7), а необходима только сигнатура, длиной в 64 байта.
В итоге пришлось написать обработку, которая выполняет то же самое, что выполнял скрипт на Python.
Обработка подписывает стандартный SOAP-конверт <envelope>, для примера в ней есть тестовый запрос. Разумеется, для подписи в системе должен стоять КриптоПро, к нему должен быть подцеплен сертификат. Пробную версию КриптоПро можно скачать и установить бесплатно на официальном сайте. Тестовый сертификат можно выпустить там же, в тестовом удостоверяющем центре.
Для получения сигнатуры и хеша используется COM-объект «CAdESCOM», поставляемый вместе с КриптоПро. Менеджер криптографии 1С используется для получения данных сертификата — издателя и открытого ключа. Можно было бы обойтись без него, но с ним удобнее. Кроме того, используется COM-объект «System.Text.UTF8Encoding» для конвертации строки в массив байт COMSafeArray в кодировке UTF8. К сожалению, на выходе у XML полностью теряется форматирование. Избежать этого не получилось, так как оно уничтожается при каноникализации средствами 1С. Обратно возвращать форматирование уже нельзя, подпись становится невалидной.
Методика не привязана к конкретному прикладному решению и работает как на сервере, так и на клиенте. Тестировалось на релизе 8.3.13.1513. На более ранних будет работать вплоть до релиза, где есть МенеджерКриптографии, ДокументDOM, ДвоичныеДанные, ПреобразованиеККаноническомуXML и функции для работы с Base64.
P.S. Буду очень благодарен, если кто-нибудь сможет ответить на пару вопросов:
1. Так как используется COM, работать все это будет только на Windows. Если конвертацию в UTF8 можно переписать на 1С, то аналога CAdESCOM в Linux нет и не будет. Может, кто знает, как можно получить хеш и сигнатуру из КриптоПро в консоли на Linux.
2. Элемент подписи создается с помощью ДокументDOM фактически вручную, то есть поэтапным созданием каждого узла. Дописать в ДокументDOM кусок получилось из объекта ФабрикаXDTO, но началась путаница с пространствами имен и каноникализацией. Возможно, все-таки перепишу с использованием фабрики и макета. А вот вставить в один ДокументDOM кусок другого ДокументDOM, созданного из макета, у меня не получилось, хотя в СП такая возможность вроде как декларируется. Если кто подскажет, как — скажу спасибо.
P.P.S. Не на тему ЭЦП, но около. Если кто-нибудь озадачится вопросом создания туннеля по стандарту ГОСТ 2012, как этого требует ГИС ЖКХ и не только он, при наличии КриптоПро с этим отлично справляется их форк STunnel — stunnel-msspi. В него уже встроены необходимые алгоритмы, при этом нет необходимости вытаскивать ключ из КриптоПро и хранить его в открытом виде, как требуется в случае использования оригинального STunnel. Достаточно только указать открытый ключ сертификата или имя хранилища в КриптоПро.
Что мы не так делаем? Что упустили?
Сделали как описано в Взаимодействие с ГИС ЖКХ с помощью stunnel и openssl по ГОСТу
Всё время получаем ответ «Ошибка формата подписи запроса»
—Простой Запрос:
| XML | ||
|
—Подписываемый узел канонизирован XML_C14N_EXCLUSIVE_1_0:
| XML | ||
|
—Хэш-сумма от подписываемого узла без последнего символа перевода строки. Первого и так не было. {digest1}:
zxghJvxT+dA7OXHxOtap46fY6Q0t5MjZAKN0fstnREw=
—Сертификат в base64 размером: 2948
MIIInjCCCE2gAwIBAgIQAdGxoWwpbAAAAGGuAxMAAjAIBgYqhQMCAgMwggFMMRgw…nJ8Uqn0xo/jhLbGWu+Xxxk0BB+41i1q/WsljRSVIYLqwa5vdxdLkCw/4ykISmOY=
—Хэш-сумма в base64 от сертификата в бинарном виде {digest2}:
6glGN/VnWyZowKMxNVjQmEKHNmyYlmHDLef5Mycx/Cc=
—Удостоверяющий центр:
OGRN=1025203036506, INN=005260013152, STREET=»ул.Ошарская, д.69″, C=RU, L=г.Нижний Новгород, S=52 Нижегородская область, E=ca@cek.ru, O=»ЗАО «»ЦЭК»»», OU=Удостоверяющий центр, CN=»ЗАО «»ЦЭК»»»
—Заменяем E= на 1.2.840.113549.1.9.1= (так в исходниках гисовского примера)
—Заменяем G= на 2.5.4.42=
—Заменяем T= на 2.5.4.12=
—Заменяем OU= на 2.5.4.11=
—Заменяем SN= на 2.5.4.4=
—Заменяем INN= на 1.2.643.3.131.1.1=
—Заменяем OGRN= на 1.2.643.100.1=
—Заменяем SNILS= на 1.2.643.100.3=
—Заменяем STREET=»ул.Ошарская, д.69″ на STREET=»ул.Ошарская, д.69″
—Заменяем двойные кавычки » на экранированные двойные кавычки «
—Результат для Удостоверяющего центра:
1.2.643.100.1=1025203036506, 1.2.643.3.131.1.1=005260013152, STREET=»ул.Ошарская, д.69″, C=RU, L=г.Нижний Новгород, S=52 Нижегородская область, 1.2.840.113549.1.9.1=ca@cek.ru, O=»ЗАО «»ЦЭК»»», 2.5.4.11=Удостоверяющий центр, CN=»ЗАО «»ЦЭК»»»
—Странно, что свойство S=52 Нижегородская область у других обозначен как ST=, а не S=
—Номер сертификата hex: 01D1B1A16C296C00000061AE03130002
—Номер сертификата integer: 2418020814927163024379796557267140610
—Узел со свойствами подписи <SignedProperties> Канонизирован XML_C14N_1_0
—Без всех переводов строк (Так в альбоме ТФФ сказано для всего узла <Signature>):
| XML | ||
|
-Хэш-сумма от узла со свойствами подписи {digest3}:
Dr5/DlTWK7HpgFS8JCGbM3VQu4e2VqsPjz43w1nlJN0=
—Узел с информацией о подписи <SignedInfo> Канонизирован XML_C14N_1_0
—Без всех переводов строк (Так в альбоме ТФФ сказано для всего узла <Signature>):
| XML | ||
|
—Подписанная хеш-сумма от узла <SignedInfo>:
qrbKvmkOTCQGVqny1MWR1zCFfdPumDl6vJKZHXiHavfd4UVzlVNWPQPkE2n3/PuygsVEJ3tQywsVX9d6+6pw0Q==
—Ответ промышленного стенда:
AUT011005 Ошибка формата подписи запроса




