Пожалуйста.
Цитата |
---|
Я понимаю, что это файлы pem... |
Скорее всего. Вообще PEM это формат ("текстовая" кодировка в base64 данных + текстовые заголовки) и расширение может быть разным. Для сертификатов в PEM общепринято .crt и windows его понимает. Если после изменения .pem на .crt отобразится сертификат, то можно посмотреть чей и все прояснится.
Отправлено спустя 15 минуты 22 секунды:Цитата |
---|
1) Если у меня лицензионный КриптоПро, то какие-нибудь проблемы из вышеперечисленных снимаются? |
В принципе да. Конечно смотря какая именно лицензия.
Во-первых,
по подписи XML. Краем глаза видел где-то на сайте КриптоПро xml-dsign-addin. По названию эта штука как раз для подписи XML, но как я понял для него нужна дополнительная лицензия, поэтому не стал разбираться к чему он addin (дополнение) и подходит ли подписанный файл к ГИС. Почему-то мне кажется, что дополнение к MS Office и к ГИС не очень подходит (предположил что потребует сохранения файла на диск, подписания, потом отправки файла, то есть нарушит "поточность" внутри программы), поэтому не стал докупать, но может быть у кого-то получится настроить и приспособить.
Если все же не допиливать чужое, а делать свое, то Delphi может обратиться к КриптоПро через майкрософтовские функции. Тут ориентиром служит модуль JwaWinCrypt (есть какой-то стандартный Crypt2 WCrypt32.pas, но в нем как я понял несколько устаревшие описания функций и без учета 64-битности) и заголовочный файл от криптопро с описанием констант. Заголовочный файл желательно посвежее от той же версии КриптоПро, что установлена. Обычно они идут с лицензией криптопро для разработчиков. У меня такой нет, нашел явно "несвежий" заголовочный файл. Впрочем скорее всего из всего файла понадобятся только 3-4 константы. В заголовочном файле констант намного больше и комментарии к ним наводят на мысль что таким же образом наверно и зашифрованный канал можно поднять, но я пока не вникал в подробности. Вот 4 константы для получения хэша и подписи, бросившиеся в глаза.[code:d1hqgczn]const PROV_GOST_2001_DH=75; //Тип Криптопровайдера. для ГОСТ большинство криптопровайдеров использует этот, исключение vipnet для него значение типа равно 2
szOID_CP_GOST_R3411='1.2.643.2.2.9'; //Функция хэширования ГОСТ Р 34.11-94
szOID_CP_GOST_R3411_R3410EL='1.2.643.2.2.3'; //Алгоритм цифровой подписи ГОСТ Р 34.10-2001
szOID_CP_GOST_R3410EL='1.2.643.2.2.19'; //Алгоритм ГОСТ Р 34.10-2001, используемый при экспорте/импорте ключей[/code:d1hqgczn]Первая - это тип криптопровайдера, указывается в CryptAcquireContext. Одновременно можно указать nil вместо имени криптопровайдера (тогда программа подхватит почти любой гостовский (кроме vipnet), выставленный "по умолчанию" для типа 75, не обязательно криптопро) или указать полное наименование криптопро (тогда другие гостовские не подхватятся, но сможет подхватится криптопро даже если криптопро не "по умолчанию" для типа 75). Наименование и выставлен ли по умолчанию можно посмотреть в настройках криптопро (там где обычно сертификат устанавливаем, на соседней вкладке).
Вторая - идентификатор функции хэширования, используется вместо szOID_RSA_MD5 в примерах. Смущает, что 94, но похоже та самая. Третья- четвертая - алгоритм подписи, пока я не понял какой именно нужен.
Если программа будет 64 разрядная, то скорее все нужно будет подправить некоторые типы в объявлениях функций.
Вычисленное криптопро значение хэша или подписи нужно будет "перевернуть". Как я понял, фокус здесь в том, что криптопро возвращает результат не в том endian, который требуется стандартом XML-DSIGN и потому приходится первый байт менять местами с последним, второй с предпоследним и так далее. Затем закодировать в base64 (это относительно легко, модулей кодировщиков много, обычно они тесно связаны с модулями для работы с XML или HTML). Далее все полученное соединить в нужном порядке. Это заслуживает отдельного освещения, условно говоря на этом с подписью все.
Во-вторых,
защищенный канал. Криптопро сделала собственную версию stunnel. Как я понял, отдельной лицензии не требуется, скачивание бесплатно с сайта криптопро. Для нее можно также переделать ключ и сертификат в pem формат как и для обычной. При этом вылезут те же самые грабли с неэкспортом .p12 из криптопро.
Однако внимания заслуживает факт, что вместо имени файла ключа в криптопрошном stunnel можно специальным образом указать ссылку на криптопро и
считать ключ из криптопро. Немного неясно, что в этом случае происходит с пин-кодом ключа - на всякий случай лучше бы скопировать контейнер, а то не дай Бог рабочий контейнер заблочится от неправильных пин-кодов.
Как работает пока не проверял, но если не придется возиться с переделкой ключа, все значительно упростится. Правда меня "терзают смутные сомнения", что если прописать криптопрошную gost_capi.dll к обычному stunnel выйдет то же самое. Хотя сертификат все также потребуется в pem, но с этим проблем нет легко переводится через openssl.
Если настроить такой stunnel, то в программе можно не заморачиваться на собственную реализация HTTPS со вкусом ГОСТ, а просто стандартными модулями HTTP соединяться с локальным портом stunnel, а уже stunnel будет соединяться с серверами ГИС, накладывать шифрование, предъявлять сертификат серверу.
Отправлено спустя 20 минуты 11 секунды:Цитата |
---|
2) В данный момент, насколько я понял, достаточно предоставления доступа организацией к собственной тестовой ИС. То есть, ИС не должна просить доступа у организации. |
Скорее всего именно так, тестовый позволяет срезать "углы", я не очень подробно изучал этот момент. Однако важно помнить, что: а) для рабочего режима доступ все равно придется запрашивать; б) если срезать много углов и не протестировать все моменты в тестовом режиме, то в рабочем вылезет немало "сюрпризов" и "подводных камней". Читал, что в СМЭВ многие удивились когда рабочий контур проверил электронные подписи и "завернул" с ошибкой сообщения, которые в тестовом контуре проходили успешно. Оказалось тестовый контур игнорирует ошибки в подписи. Поэтому даже если тестовый сервер чего-то не требует, это не значит что нужно это спокойно пропустить.
Отправлено спустя 5 минуты 23 секунды:Можете считать это перестраховкой с моей стороны, но я все равно бы пострался максимально придерживаться процедуры рабочего режима. Раз уж зашла об этом речь, в тестовом режиме еще используется специальный признак тестового режима, при указании которого в рабочем запрос будет отклонен.
Отправлено спустя 14 минуты 4 секунды:Цитата |
---|
3) Вот я сгенерировал PAS из WSDL. Какие дальнейшие действия? Надо ли авторизоваться на ГИС из программы. В какой момент можно передавать данные? Мрак! Методичек нет и не предвидится. |
Да, вот так и собираем истину по крупицам.
![Улыбается :)](/upload/main/smiles/3/icon_e_smile.gif)
Как я понимаю, в данном случае зашифрованный канал требует предъявления сертификата клиента, при этом часть данных шифруется при помощи ключа клиента, сервер расшифровывает их ключом проверки из предъявленного сертификата и так доказывается, что у клиента есть ключ, соответствующий сертификату. То есть процедура установления зашифрованного канала по сути аналогична входу по сертификату на ЕСИА. Соответственно, дополнительная авторизация из программы не нужна - ГИС определит пользователя по сертификату защищенного соединения.
Получается передавать данные можно сразу после установления соединения - в смысле сначала заголовки протокола HTTP уточняющие: адрес страницы куда соединяемся, метод (POST я полагаю), тип, кодировку и длину "тела запроса", потом собственно данные в виде "тела запроса". Как-то так, заголовки наверняка описаны в документации, но сложно навскидку найти 1 нужный абзац среди сотен страниц текста.
Отправлено спустя 59 минуты 54 секунды:Цитата |
---|
Вот я сгенерировал PAS из WSDL. |
Как-то это меня настораживает. Непохожие языки, как они перегенерятся? Да и вообще вроде XML должен на выходе программы получаться.
Цитата |
---|
Какие дальнейшие действия? |
Надеюсь немного пролил свет - дальше настроить stunnel, сделать xml, подписать, коннектиться по http на stunnel, передать данные и получить ответ ГИС
Цитата |
---|
с какой целью они прислали сертификат обратно |
Родилось безумное предположение, что ГИС не принимает сертификаты аккредитованных удостоверяющих центров и они перевыпустили сертификат на своем удостоверяющем центре. Совпадает ли издатель в исходном сертификате и полученном от них?