настройка stunnel криптопро windows
Настройка stunnel криптопро windows
Клиент Stunnel (Linux) принимает трафик на указанном порте 1500 по адресу 192.168.69.180, шифрует все поступившие на него данные и передает их на Stunnel Сервер (Windows) с IP адресом 192.168.69.61 на порт 1502. Сервер расшифровывает все поступившие на этот порт данные и передает на указанный в настройках порт и адрес (google.ru, порт 80).
Если требуется проверка сертификата клиента, нужно назначить параметр «Verify=2».
Установка на ОС Linux
Дополнительный пакет (входит в состав дистрибутива):
Установка пакета Stunnel
Для дистрибутивов Linux, основанных на rpm, это утилита rpm:
Для дистрибутивов, основанных на deb, это утилита alien:
После установки пакета бинарные файлы, предназначенные для запуска Stunnel, будут помещёны в /opt/cprocsp/sbin/ /. Существует две реализации службы Stunnel: с использованием библиотеки thread и с использованием fork; бинарные файлы называются stunnel_thread и stunnel_fork соответственно. Stunnel с использованием fork возможно использовать только с КриптоПро CSP исполнение КС2.
Установка сертификата
Требуется установить необходимые сертификаты:
а) сертификат корневого Центра Сертификации (ЦС) – в хранилище «Доверенные корневые Центры Сертификации» локального компьютера
Запуск службы
Запуск службы будет выполняться под тем пользователем, под которым был установлен сертификат.
Установка на ОС Windows
Для работы необходимо установить:
Установка службы Stunnel
Установка делается путём запуска stunnel.exe – install
В дальнейшем служба для старта будет использовать файл stunnel.exe из той папки, откуда была проведена установка.
Перед установкой нужно выбрать режим работы службы, установить сертификаты и сформировать файл конфигурации.
Установка сертификата
Требуется установить необходимые сертификаты:
а) сертификат корневого Центра Сертификации (ЦС) – в хранилище «Доверенные корневые Центры Сертификации» локального компьютера;
Запуск службы по умолчанию выполняется от пользователя «SYSTEM»
Получается следующая цепочка:
Данная программа позволяет создавать TLS-«туннель», обеспечивающий шифрование трафика от клиента до сервера с использованием сертифицированного СКЗИ произвольного TCP-соединения.
Подробные настройки по использованию Stunnel
Шифрование TLS-трафика по алгоритмам ГОСТ-2012 c Stunnel
В этой статье я хочу показать, как настроить Stunnel на использование российских криптографических алгоритмов в протоколе TLS. В качестве бонуса покажу, как шифровать TLS-канал, используя алгоритмы ГОСТ, реализованные в криптоядре Рутокен ЭЦП 2.0.
Но для начала давайте вообще разберёмся для чего нужен Stunnel. В двух словах — это программа, на которую можно переложить всю логику шифрования трафика между сервером и клиентом. Делается это следующем образом: допустим у вас есть клиент и сервер, которые общаются между собой без использования шифрования, аутентификации и проверки целостности. Вы могли бы переписать клиент и сервер так, чтобы все исходящие и входящие сообщения передавались между собой с учётом всех этих моментов, но для чего такие сложности, если можно это просто переложить на плечи другому приложения? Для решения такой задачи как раз подойдёт Stunnel.
Вам нужно просто настроить клиент таким образом, чтобы весь свой трафик он передавал на клиентский Stunnel, в свою очередь, он устанавливает безопасное соединение с сервером, отправляя данные на серверный Stunnel. Stunnel на сервере расшифровывает пришедший трафик и перенаправляет данные на вход серверу. Вышесказанное проще осознать глядя на эту диаграмму
Стоит заметить, что на сервере не обязательно должен стоять именно Stunnel, для работы с криптографическими алгоритмами. Здорово, что есть готовые демонстрационные стенды, которые поддерживают российскую криптографию, список которых есть в презентации с РусКрипто’2019.
Нам нужны стабильно работающие серверы, осуществляющие двухстороннюю аутентификацию.
Мы выбрали серверы КриптоПро как наиболее надёжные с полной реализацией стандарта ГОСТ TLS. Спасибо им за это 🙂
Звучит достаточно просто, давайте попробуем организовать этот процесс.
Подготовительный шаг
OpenSSL для Windows можно взять отсюда, а для пользователей линукса — из репозиториев или собрать самому, скачав свежую версию отсюда. Также его можно взять из Rutoken SDK, из директории openssl\openssl-tool-1.1, этот архив нам будет полезен и дальше, т.к. в нём находится интересующий нас rtengine. Stunnel можно найти здесь. Для работы необходима версия >= 5.56.
Скачать rtengine можно из Rutoken SDK, он лежит в директории openssl\rtengine\bin. Закинуть его нужно туда, где хранятся все движки openssl. Узнать путь до них можно с помощью
Но просто переместить движок в нужную папку — мало, нужно ещё сконфигурировать сам openssl для работы с ним. Узнаём где лежит файл с конфигурацией openssl.cnf с помощью той же команды, что указана выше (под виндой stunnel идёт с собственной версией openssl, поэтому файл с конфигурацией лежит в path\to\stunnel\config\openssl.cnf
Давайте проверим, что rtengine подключился, для этого подключим токен и выведем список всех алгоритмов шифрования:
Напомню, что в Windows нужно проверять на openssl, который лежит рядом с stunnel
Если среди них будут присутствовать наши ГОСТы, значит всё настроено верно.
Настало время самого интересного: проверка установки соединения по ГОСТу с тестовыми серверами КриптоПро. Список данных серверов описан здесь (https://www.cryptopro.ru/products/csp/tc26tls). Каждый из этих серверов работает со своими алгоритмами для аутентификации и шифрования. Более того на портах 443, 1443, 2443,… запущены сервисы, которые воспринимают только определённые парамсеты. Так, например, по адресу http://tlsgost-256auth.cryptopro.ru происходит шифрование с аутентификацией с использованием алгоритмов GOST2012-GOST8912-GOST8912 и 256-битным ключом. Так же на порту 443 используется XchA-ParamSet, на порту 1443 — XchB-ParamSet, на порту 2443 — A-ParamSet и т.д.
Теперь, когда мы знаем, какой ключ нам нужен, давайте получим корневой сертификат от тестового сервера, выработаем ключи для работы и подпишем запрос на наш сертификат.
Простой способ (работает под Windows и Linux)
Через командную строку
Для того, чтобы получить корневой сертификат, зайдём на сайт тестового УЦ ООО «КРИПТО-ПРО». И нажмём на кнопку для получения сертификата. Отобразится новая вкладка, в которой нужно будет выбрать метод шифрования Base64 и нажать на кнопку «Загрузка сертификата ЦС». Полученный файл certnew.cer сохраняем.
Теперь генерируем ключи.
Стоит заметить, что сгенерированные на токене ключи не могут быть скопированы с токена. В этом состоит одно из основных преимуществ их использования.
Создадим запрос на сертификат:
Опять открываем сайт тестового УЦ, но на этот раз нажимаем на кнопку «Отправить готовый запрос PKCS#10 или PKCS#7 в кодировке Base64». Вставляем в поле содержимое нашего запроса, нажимаем на кнопку Выдать и загружаем сертификат user.crt в формате Base64. Полученный файл сохраняем
Остался последний вопрос: Для чего всё это. Зачем мы получали все эти сертификаты, ключи и запросы?
Дело в том, что они нужны протоколу TLS для двусторонней аутентификации. Работает это очень просто.
У нас есть сертификат сервера, и мы считаем его доверенным.
Наш клиент проверяет, что сервер, с которым мы работаем имеет аналогичный сертификат.
Сервер же хочет убедиться, что работает с пользователем, который ему известен. Для этого мы и создавали запрос на сертификат для работы через наши ключи.
Мы отправили этот запрос и сервер подписал её своей ЭЦП. Теперь мы можем каждый раз предъявлять этот сертификат, подписанный корневым УЦ, тем самым подтверждая, что мы — это мы.
Конфигурирование Stunnel
Осталось только правильно настроить наш туннель. Для этого создадим файл stunnel.conf с настройками Stunnel по умолчанию и напишем туда следующее:
Теперь, если всё сделано правильно, можно запустить Stunnel с нашей конфигурацией и подключиться к серверу:
Откроем браузер и зайдём по адресу localhost:8080. Если всё верно, то отобразится следующее:
Если же нет, то смотрим логи и используем отладчик, чтобы понять в чём же всё-таки проблема.
Если у вас остались какие-то вопросы, то милости просим в комментарии 🙂
Экономим бюджет компании, или как построить криптотуннель по ГОСТу с минимальными затратами
Обеспечение безопасности при помощи средств криптографической защиты информации (СКЗИ) — не очень сложная задача, если все технологические участки находятся на хост-машине. Однако для того чтобы передавать и шифровать информацию одновременно, необходимо построить грамотный технологический процесс программного обеспечения. Мы расскажем, как это сделать.
Введение
Для любого системного администратора или DevOps построить VPN или «пробросить» нестандартный метод инкапсуляции пакетов (туннелирование) — не очень сложная задача. Часто для этого применяют OpenVPN, если планируется постоянное использование, либо SSH-туннелирование, если защищённое соединение нужно на один-два раза. Однако есть предприятия и ведомства, которые должны соблюдать строгие условия передачи данных, установленные законодательством. Под такие требования подпадают, например, многие структуры, которые так или иначе имеют отношение к денежным операциям: банки, микрофинансовые организации и т.п. Персональные данные тоже являются «защищаемой информацией» во всех законах и положениях.
В результате оказывается, что при шифровании необходимо использовать СКЗИ со всеми необходимыми сертификатами и лицензиями, соответствующие нормативным требованиям. Одним из примеров таких программных средств является «КриптоПро CSP». В данной статье мы будем разбирать задачу о том, как «прокинуть» средствами stunnel сетевой туннель, который будет шифроваться «КриптоПро CSP», заодно получив хоть и тестовый (на 3 месяца), но полностью валидный сертификат по ГОСТ Р 34.10-2012.
Задача
Для начала необходимо разобраться в том, как всё описанное будет работать, и поставить конкретные задачи.
К примеру, есть две машины. Для демонстрации настройки двух операционных систем одна из них будет работать под управлением ОС семейства Linux (Ubuntu, версия не важна, но желательно — не ниже 16), вторая — под Windows 10. На win-системе будет запускаться Netcat на прослушивание какого-то определённого порта, а с nix-системы будут передаваться пакеты. Таким образом, Windows-машина будет сервером (в том числе — в отношении настроек stunnel).
Что должно получиться в итоге? При подключении с Linux к Windows через программу Netcat все пакеты будут шифроваться сертификатом GOST_2012 и сертифицированным программным обеспечением. Задача тривиальна и ставится для того, чтобы показать возможность такого манёвра. Поскольку stunnel передаёт любой протокол внутри себя, можно, к примеру, подписывать XML-файлы секретной подписью другой организации или передавать персональные данные в хранилище через интернет.
Тестовый стенд
Linux
Начнём с того, что система готова к настройке. Как работает «КриптоПро CSP», читатели, скорее всего, уже знают. Небольшое уточнение относительно stunnel: эта программа изначально создавалась как прокси-сервер с функцией шифрования трафика. Другими словами, она берёт, к примеру, HTTP и превращает его в своего рода HTTPS (если не вдаваться в подробности протоколирования).
Работает stunnel следующим образом: при запуске на локальной машине открывается определённый порт, указанный в конфигурационном файле, и в тот же момент приложение соединяется со своей копией на другой машине. Таким образом все пакеты, попавшие на порт localhost, шифруются, затем проксируются на другую систему и там расшифровываются. Удобство схемы состоит в том, что это — просто шлюз, которому неважно, какой протокол шифровать и передавать.
Рисунок 1. Схема работы stunnel
Изначально загружаем необходимый продукт «КриптоПро» отсюда. В скачанном архиве будет примерно такой набор файлов, как на скриншоте.
Рисунок 2. «КриптоПро CSP» на Linux
Для установки необходимо запустить install.sh. Этот скрипт добавит нужные компоненты: certmgr, cpverify, cryptcp, csptest, csptestf, curl, der2xer, genkpim, inittst, wipefile. У каждой из этих программ — своя зона ответственности, свои ключи и задачи. Для нашего сценария нужны будут только certmgr и cryptcp.
Сама по себе stunnel шифрует трафик с помощью OpenSSL, но в компании «КриптоПро» её переписали под свои нужды, так что теперь она использует утилиты для un- и de- шифрования и называется stunnel-msspi. Поставляется она в архиве вместе с CSP; также её можно скачать отдельно. Для старых версий «КриптоПро CSP» есть вероятность, что программа уже установлена, но это необходимо проверить.
Как было сказано выше, для stunnel Linux-система будет клиентом, а Windows — сервером. IP-адреса: Linux – 172.22.1.65, Windows – 172.22.1.121.
Следующий шаг — ключи и сертификаты. Для сервера нам необходимо и то, и другое, причём все это — в контейнере «КриптоПро». Для клиента требуется только сертификат, нужный для того, чтобы к туннелю не мог подключиться любой желающий. Забегая немного вперёд, отметим, что в конфигурационном файле stunnel есть опция verify, и вот её параметры:
0. Не проверять сертификат сервера
1. Проверять сертификат при его наличии
2. Проверять сертификат всегда
3. Проверять наличие данного сертификата в хранилище TrustedUsers
Начиная с параметра 1, собственно, и нужен сертификат клиента для защиты подключения.
Итак, чтобы сгенерировать контейнер для сервера, необходимо воспользоваться утилитой cryptcp:
Интересные моменты относительно ключей:
Рисунок 3. Вывод программы cpconfig
На скриншоте выше видно, что значение 75 устарело и соответствует ГОСТу версии 2001. ГОСТ версии 2012 на 256 и 512 бит задаётся значениями 80 и 81 соответственно.
Выше описаны самые «пикантные» моменты, которые могут отнять много времени. Остальные ключи и другие пояснения можно найти в документации.
Переходим к генерации сертификата для клиента. Команда аналогична, меняется только имя контейнера и идентификатор назначения сертификата.
Теперь с ключами и сертификатами всё готово. На всякий случай приведём команду экспорта из контейнера:
Таким образом можно получить «на руки» сертификат в формате DER.
Далее нужно приниматься за настройку stunnel, а именно — его конфигурационного файла. Создаём в удобном месте файл stunnel.conf. Содержимое будет следующим:
Прокомментируем содержание секции TestStunnel:
Рисунок 4. Отпечаток в Linux
На этом настройка Linux закончена, можно запускать stunnel с указанием соответствующего файла конфигурации stunnel.conf.
Windows
После установки «КриптоПро CSP» необходимо скопировать контейнер с серверным ключом и сертификатом с nix-машины.
Для этого необходимо скачать и установить ImDisk. Затем при помощи ImDisk Virtual Disk Driver следует создать эмулятор токена (именно так его и увидит CSP, по-русски это — просто контейнер HDD) и подключить его к системе.
Рисунок 5. Псевдотокен
В итоге рядом с жёстким диском должен появиться ещё один носитель — это и есть токен. Туда понадобится скопировать папку с контейнером. После этих манипуляций сертификат нормально установится в «КриптоПро CSP».
Дополнительно стоит скопировать клиентский сертификат на сервер и тоже его установить.
Конфигурационный файл для stunnel-msspi:
Здесь всё устроено по аналогии с конфигурационным файлом клиента: accept — порт, к которому подключается клиентская копия stunnel (должен быть разблокирован в брандмауэре и «проброшен» во все места до наружного выхода), connect — порт для приложения (в данном случае — Netcat).
Повторяется история и в отношении сертификата: либо импорт из контейнера, что совсем не рекомендуется, либо указание отпечатка. Отпечаток можно найти в составе сертификата.
Рисунок 6. Отпечаток сертификата в Windows
Журнал для отладки можно будет отключить тогда, когда всё будет настроено как часы.
Теперь пора скачать Netcat для Windows.
Следующий шаг — запустить сервер stunnel, заодно перезапустив и клиент. Для отладки и тестирования в Windows лучше делать это из командной строки.
В командной строке сервера побежит протокол, который расскажет, что кто-то успешно подключился. Пишем в одном окне набор символов; он появляется в другом окне. Всё настроено верно.
Рисунок 7. Результат
Выводы
В статье мы разобрали задачу о том, как получить криптотуннель с валидным ключом, подписанным самим «КриптоПро», и с алгоритмом шифрования GOST_2012, 512 бит. Сделано это с минимальными затратами — две лицензии на «КриптоПро CSP».
Можно, конечно, написать что-то своё, но лицензии JСP, к примеру, стоят намного больше. Готовые решения тоже будут значительно дороже.
Stunnel на сервере и клиенте
Задача
Обеспечить доступ из «везде где есть интернет» к некоему ПО. Шифровать траффик между клиентской и серверной частью приложения, которое не умеет работать через SSL. Так же нужно иметь возможность ограничивать доступ некоторым пользователям при необходимости. По различным причинам основные реализации VPN отпали. В процессе поиска решения наткнулся на Stunnel, который идеально подошел. В данной статье постараюсь детально описать процесс настройки.
Статья по большей части составлена из рабочих заметок в довесок с претензиями на туториал, поэтому прошу спокойно относится к капитанству вида — «Первое, что мы сделаем — обновим систему».
Общее представление схемы работы:
ПО клиент (windows) > Stunnel > Интернет > Stunnel > ПО Сервер (linux)
Система: свежеустановленная ubuntu server 14.04 x64.
Приложение трафик которого нужно шифровать я называть не буду. Вместо него буду указывать ssh. Для теста подходит идеально, на мой взгляд.
Приступим
Первое, что мы сделаем — обновим систему:
Настроим и включим ufw:
Проведем некоторые подготовительные мероприятия.
Разрешим автозапуск. В файле /etc/default/stunnel4 заменим ENABLED=0 на ENABLED=1:
Создадим папки для клиентских сертификатов. certs — разрешенные, crls — запрещенные (отозванные). О самих сертификатах чуть позже.
Создадим лог-файл и сменим владельца.
Я не считаю размещение логов в месте отличном от /var/log хорошей идеей, но заставить stunnel писать логи за пределы окружения мне не удалось.
Я буду использовать свой конфиг, но если он вам не подходит можно взять пример в /usr/share/doc/stunnel4/examples
Создадим конфигурационный файл:
Со следующим содержимым:
Ключи и сертификаты
Не большое отступление. В нашем случае stunnel проверяет только корректность пары сертификат/ключ и наличие сертификата в разрешенных или запрещенных. Самоподписанного сертификата более чем достаточно, и с технической стороны (stunnel) и со стороны поставленной задачи. Нет никакого смысла заморачиваться с собственным CA или с присутствием корневого сертификата в списке доверенных на клиенте или сервере.
Нам нужны пары сертификат/ключ для сервера и каждого клиента.
C помощью openssl создадим пару для сервера:
Отвечаем на вопросы:
И переместим их по назначению:
Как и где хранить клиентские сертификаты с ключами (за исключением каталогов certs и crls созданных ранее) решать вам. Я просто создам каталог clients в домашней директории своего пользователя и буду хранить их там на первых порах.
Создадим каталог и перейдем в него:
Создадим пару для клиента:
Как и при создании сертификата для сервера отвечаем на вопросы. Common Name будет другим например client.
Создадим еще одну пару:
Предположим, что clientcert.pem сертификат клиента которому доступ разрешен, а dnclientcert.pem сертификат клиента которому доступ запрещен. Скопируем сертификаты по нужным директориям.
Для каждого сертификата нужно создать хэш-ссылки (Возможно «хэш-ссылка» не корректное название, но оно очень точно передает суть). Это можно сделать с помощью утилиты c_rehash из пакета openssl. Мы же создадим небольшой скрипт для этих целей.
Со следующим содержимым:
Возможно будет более целесообразным разместить certlink.sh где нибудь в /usr/bin. Я пока не стал этого делать. Но выбор за вами.
Дадим права:
В результате в каталогах у нас должны появится ссылки вида 7469493f.0.
Stunnel на клиенте
На клиенте будем использовать версию stunnel аналогичную серверной. На сервере у нас 4.53. Забираем с одного из зеркал.
Если прямая ссылка перестанет работать, найти нужную версию можно так:
Редактируем файл stunnel.conf. У меня он имеет следующий вид:
Здесь debug = 7 только на момент отладки, потом можно понизить до 3 или 4. Также есть опции для «тихого режима» и сокрытия значка в трее все есть в man’e.
Запускаем stunnel.exe, и пробуем с помощью putty подключится к 127.0.0.1. Тестируем. Можно попробовать подключится с запрещенным сертификатом.
Полезные материалы
Приведенные здесь инструкции полностью работоспособны. Проверено 26.12.2014 ubuntu 14.04.01, stunnel 4.53.
В данный момент работаю над парсингом логов stunnel с выводом отчетов и автоматизацией создания/управления сертификатами. Так как в последнее время мне интересен golang, реализовано будет с помощью него. Если материал на эту тему интересен — дайте знать.
Взаимодействие с ГИС ЖКХ с помощью stunnel и openssl по ГОСТу
Встала перед нами в полный рост задача наладить взаимодействие с ГИС ЖКХ. Согласно документации, предполагается использование небезызвестного отечественного ПО для шифрования туннеля и формирования ЭЦП по ГОСТу, но это не наш метод. Вооружившись гуглом и консолью, я и slavam реализовали необходимый функционал подручными средствами.
Всё необходимое ПО есть как на Linux, так и на Windows платформах, потому методику можно назвать мультиплатформенной.
Подготовка
Думаю, ничего сложного быть не должно и всё уже сотни раз описано. А в более свежих дистрибутивах модуль gost есть из коробки.
OpenSSL используется двояко: с ним собран stunnel, что-бы работал по ГОСТу; и утилита openssl вызывается из кода python-а для формирования и проверки подписей. Вызов openssl обусловлен тем, что не удалось из кода python-на задавать используемый крипто-модуль. Всё необходимое ПО есть как на Linux, так и на Windows платформах, потому методику можно назвать мультиплатформенной.
Для python-а сервера CentOS 6 нужно будет обновить библиотеку lxml, а для этого поставить несколько дополнительных пакетов:
Так же нам потребуются файлы сертификата и закрытого ключа в формате PKCS12 (.pem). Получить их из eToken-а можно с помощью утилит вроде P12FromGostCSP или вручную. Если сделать это по каким-либо причинам не получается, то есть вариант работы с ключом «Рутокен ЭЦП» напрямую. На сайте есть подробные инструкции, как обучить этому OpenSSL и stunnel. Таким образом, задача сводится к предыдущей. У меня под рукой такого ключа не оказалось, потому проверить не удалось.
Криптотуннель по ГОСТу
Туннель поднимается с помощью Stunnel, который работает в режиме прокси. Нужно только научить его использовать модуль gost. Но тут есть момент — чтобы модуль инициализировался правильно, нужно слегка исправить исходники. Проблема, как я понял, связана с порядком инициализации модуля и методов. Итак:
Правим файл src/options.c и в конце функции » NOEXPORT char *engine_init(void) » добавляем вызов SSL_library_init();.
Решение было найдено тут.
Собираем с подключением ранее собранного OpenSSL:
Файл конфигурации /etc/stunnel.conf:
Файлы сертификатов кладём в директорию /etc/crypto/. В общем случае, stunnel может работать под любым пользователем, но у нас пусть будет root.
Если вывод совсем не похож, то внимательно смотрим в лог файл /var/log/stunnel.log.
Формирование XMLDSig
Когда туннель до сервера ГИС ЖКХ настроен и работает, можно слать туда всякие запросы и получать нужные ответы. Запрос отправляется в виде XMLDSig, в котором содержится сам запрос, хеш этого запроса, хеш сертификата, сам сертификат, подпись хеша запроса с хешем сертификата и куча полей, всё это описывающих. Самое сложное как раз было раскрутить всю цепочку и получить XML, который успешно проходит проверку со стороны ГИС ЖКХ. Все подписываемые блоки берутся в каноническом виде, а получаемые подписи и хеш-суммы кодируются в BASE64.
Алгоритм формирования XMLDSig можно реализовать используя любой удобный язык программирования. Мы использовали python 2.7.11, демонстрационный код прилагается. Как пример, буду так же приводить консольный аналог.
0. Из сертификата достаются серийный номер и данные о выпустившем, генерируются необходимые id и запоминается текущее время.
1. С помощью любого soap клиента (например, suds на Python) формируется SOAP-запрос к серверу ГИС ЖКХ.
* openssl с поддержкой ГОСТ. Engine указан явно, но, настроив openssl.cnf, можно этого и не делать.
4. Используя полученные данные, формируется содержимое тега (см. Шаблон), канонизируется алгоритмом C14N (exclusive=False) и от содержимого считается digest3 (BASE64).
где SignedInfo.xml – уже канонизированный блок, без последнего перевода строки.
6. Все полученные значения вносятся в
Этот шаблон удалось сформировать расковыряв и проанализировав комплекс, который рекомендует использовать ГИС ЖКХ. Сам он находится в свободном доступе, но для работы требует СКЗИ КриптоПро CSP и СКЗИ Trusted Java 2.0.
7. Для того, чтобы проверить сформированную таким образом подпись, необходимо проделать все действия в обратном порядке. Консольный вариант проверки подписи:
где signature.sig – раскодированная из BASE64 подпись, а SignedInfo.xml проверяемый блок . целиком. Значения хеш-сумм просто сравниваются.
Демонстрационный код на python-е можно взять и использовать (на свой страх и риск) отсюда. Автор кода — Вячеслав (@slavam, RO). Подобный алгоритм можно реализовать средствами любого удобного языка, без необходимости покупки каких-либо дополнительных средств и компонентов. Вызов утилит OpenSSL из кода хоть и выглядит топорным, зато работает как на Linux так и на Windows платформе и позволяет отказаться от использования КриптоПро и дополнительных компонентов.
Система взаимодействия с ГИС ЖКХ у нас ещё на стадии создания, но получаемый XMLDSig проходит необходимые проверки.
Надеемся, эта статья облегчит кому-нибудь задачу по реализации подобного велосипеда.
2. В файле конфигурации явно указать его использование:
Чтобы точно определить, от куда OpenSSL читает конфигурацию, можно выставить переменную окружения: