Статус: Активный участник
Группы: Участники
Зарегистрирован: 05.08.2019(UTC) Сообщений: 65
Сказал(а) «Спасибо»: 4 раз
|
Автор: Дмитрий Пичулин Автор: rmussalimov Автор: Дмитрий Пичулин Т.е. проблема в том, что OpenSSL не определяет .so как engine? Нет, не в этом. Хорошо, спасибо. Переустановлю OpenSSL Скажите, пожалуйста, возможно ли установить голый OpenSSL, без nginx, по инструкции, которую Вы отправили выше?
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 05.08.2019(UTC) Сообщений: 2
|
Автор: Дмитрий Пичулин Автор: simpleman66 На сервере с настроенным nginx+gostengy+ГОСТ2012 сертификатами в случае если у одного из хостов истекает срок действия сертификата, то отказывается работать nginx. Т.е. перестают работать абсолютно все вирт хосты. В логе при этом ошибка: [emerg] 2169#2169: ENGINE_load_private_key("9867b5ab2b2c88342766gg5e99a6a7c6ddc7e324") failed (SSL: error:80015033:lib(128):gng_support_getuserkey:GNG_ERR_LICENSE error:26096080:engine routines:ENGINE_load_private_key:failed loading private key) Считаю это неправильным поведением, когда из-за одного просроченного сертификата использующимся один из хостов, перестают работать несколько десятков других хостов. Задал вопрос в комьюнити Nginx - авторы говорят пишите авторам gostengy https://forum.nginx.org/read.php?21,285094,285099Помогите пожалуйста решить эту проблему. При разработке у нас был другой подход, что прохождение всех проверок при старте системы, гарантирует дальнейшую работоспособность. То есть, рядовому пользователю проще сразу нарваться на ошибку, чем разбираться с ней в процессе работы. Ваша ситуация понятна, опытным пользователям такой подход может показаться наивным, но всегда можно оперативно отключать проблемные хосты на уровне конфигурации. Предлагайте свои варианты, как бы вы хотели улучшить старт системы. Я предлагаю чтобы система все же стартовала, но при этом как и сейчас предупреждала пользователя в лог и на экран (во время старта) о том что сертификат истек и как и сейчас показывала идентификатор истекшего сертификата для быстрого поиска проблемного серта. На данный момент у нас в организации например 50 хостов с разными сертификатами и когда у меня из-за одного истекшего сертификата упали оставшиеся 49 хостов, для нас это было большой проблемой. А что касается рядовых пользователей, то связку nginx+gostengy+ГОСТ2012 не так то просто установить и настроить, т.е. среди пользователей нет рядовых, есть скорее малоопытные и опытные как мне кажется. Но какой бы не был пользователь его в любом случае не ждет ничего хорошего в случае падения всей системы из-за одного хоста/сертификата. Описанное выше считаю необходимым, а вот еще есть одно пожелание, но это уже скорее прихоть чем необходимость: Можно ли как-то систему научить заранее предупреждать в лог о том что какой-то из сертификатов истекает? Это было бы крайне удобно в условиях большого количество хостов использующих различные сертификаты.
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 05.08.2019(UTC) Сообщений: 65
Сказал(а) «Спасибо»: 4 раз
|
Это невообразимо странно, что для того, чтобы поставить Engine необходим nginx
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 05.08.2019(UTC) Сообщений: 3
|
А я могу использовать gostengy, чтобы с помощью OpenSSL подписать запрос на сертификат ГОСТ2012?
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 05.08.2019(UTC) Сообщений: 65
Сказал(а) «Спасибо»: 4 раз
|
После долгих мучений удалось установить gostengy engine. Попытался подписать текстовик следующей командой: Цитата:/opt/cprocsp/cp-openssl-1.1.0/bin/amd64/openssl smime -engine gostengy -sign -inkey /*Путь до приватного ключа/Приватный ключ.pem*/ -signer /*Путь до сертификата/Сертификат.crt*/ -outform pem -in /root/message.txt -out /root/message.signed.txt -passin pass:/*Пароль от хранилища*/ Получаю следующее: Цитата:engine "gostengy" set. unable to load signing key file 140359923443456:error:0606F090:digital envelope routines:EVP_PKCS82PKEY:method not supported:crypto/evp/evp_pkey.c:48: 140359923443456:error:0907B00D:PEM routines:PEM_read_bio_PrivateKey:ASN1 lib:crypto/pem/pem_pkey.c:87: Алгоритм серта - ГОСТ 2001. Это может быть связано? Или может быть, синтаксис у нового OpenSSL другой? На другом сервере стоит старый OpenSSL, с пока еще невыпеленным gost engine , все работает. Спасибо большое.
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 395 раз в 366 постах
|
Автор: 0dm1n А я могу использовать gostengy, чтобы с помощью OpenSSL подписать запрос на сертификат ГОСТ2012? Технически да, в обычной команде подписи запроса на сертификат в параметре ключа УЦ вместо имени файла pem, которым подписывать, используйте "c:"+ имя контейнера КриптоПро(без кавычек и плюсов, слитно), которым хотите подписать сертификат. Заметьте, что сгенерировать через gostengy не получится, контейнер с закрытым ключом должен быть уже готов. На основе контейнера через gostengy отлично получается создавать запрос на сертификат или самоподписанный корневой сертификат для внутреннего неаккредитованного УЦ. Естественно без аккредитации УЦ сертификат (даже неотличимый по содержимому от квалифицированного) будет считаться неквалифицированным, недоверенным и не будет приниматься федеральными органами. Чтобы сделать "неотличимый по содержимому от квалифицированного" понадобится редактировать конфиг OpenSSL. Цитата:Алгоритм серта - ГОСТ 2001. Это может быть связано? Или может быть, синтаксис у нового OpenSSL другой? На другом сервере стоит старый OpenSSL, с пока еще невыпеленным gost engine , все работает. Спасибо большое. Вы наверно не прочитали второе сообщение этой темы внимательно. gostengy работает только с ключами в контейнерах КриптоПро, с ключами формата pem не работает и их не загружает - ошибка как раз говорит об этом. Это же касается gost_capi от КриптоПро.
Криптокомовский gost модуль реализует криптографические операции самостоятельно и есть возможность передать в него закрытый ключ из pem файла. gost_capi и gostengy не реализуют криптографические операции самостоятельно, а обращаются к криптопровайдеру КриптоПро CSP, который возвращает модулю не сам закрытый ключ, а дескриптор и принимает тоже действительный дескриптор, возможности передать через модуль закрытый ключ из pem файла нет. Соответственно вытащить через модуль закрытый ключ тоже не получится - каждый раз будет возвращаться разный дескриптор. Через некоторое время дескриптор будет уже недействителен и потому сохранять дескриптор в файл смысла не имеет.
Используйте "c:"+ имя контейнера вместо имени pem файла. Если сертификат установлен в хранилище КриптоПро, то можно также попробовать указывать отпечаток или CN. Соответственно есть сомнение в нужности указания пароля - КриптоПро обычно не принимает пароль от модуля и запрашивает пароль контейнера в своем интерфейсе (не уверен как это выглядит на *nix). Алгоритм ГОСТ 2001 поддерживается в gostengy - в этом плане пока проблемы нет. "Пока" в том смысле, что gostengy работает через криптопровайдер КриптоПро, а там гост-2001 скорее всего будет заблокирован 31 декабря 2019 года. На всякий случай можно проверить выполнены ли рекомендации по переносу даты блокировки или отключению контроля ключей (смотрите в базе знаний КриптоПро). Отредактировано пользователем 6 августа 2019 г. 5:54:45(UTC)
| Причина: Не указана
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 05.08.2019(UTC) Сообщений: 65
Сказал(а) «Спасибо»: 4 раз
|
Автор: two_oceans Автор: 0dm1n А я могу использовать gostengy, чтобы с помощью OpenSSL подписать запрос на сертификат ГОСТ2012? Технически да, в обычной команде подписи запроса на сертификат в параметре ключа УЦ вместо имени файла pem, которым подписывать, используйте "c:"+ имя контейнера КриптоПро(без кавычек и плюсов, слитно), которым хотите подписать сертификат. Заметьте, что сгенерировать через gostengy не получится, контейнер с закрытым ключом должен быть уже готов. На основе контейнера через gostengy отлично получается создавать запрос на сертификат или самоподписанный корневой сертификат для внутреннего неаккредитованного УЦ. Естественно без аккредитации УЦ сертификат (даже неотличимый по содержимому от квалифицированного) будет считаться неквалифицированным, недоверенным и не будет приниматься федеральными органами. Чтобы сделать "неотличимый по содержимому от квалифицированного" понадобится редактировать конфиг OpenSSL. Цитата:Алгоритм серта - ГОСТ 2001. Это может быть связано? Или может быть, синтаксис у нового OpenSSL другой? На другом сервере стоит старый OpenSSL, с пока еще невыпеленным gost engine , все работает. Спасибо большое. Вы наверно не прочитали второе сообщение этой темы внимательно. gostengy работает только с ключами в контейнерах КриптоПро, с ключами формата pem не работает и их не загружает - ошибка как раз говорит об этом. Это же касается gost_capi от КриптоПро.
Криптокомовский gost модуль реализует криптографические операции самостоятельно и есть возможность передать в него закрытый ключ из pem файла. gost_capi и gostengy не реализуют криптографические операции самостоятельно, а обращаются к криптопровайдеру КриптоПро CSP, который возвращает модулю не сам закрытый ключ, а дескриптор и принимает тоже действительный дескриптор, возможности передать через модуль закрытый ключ из pem файла нет. Соответственно вытащить через модуль закрытый ключ тоже не получится - каждый раз будет возвращаться разный дескриптор. Через некоторое время дескриптор будет уже недействителен и потому сохранять дескриптор в файл смысла не имеет.
Используйте "c:"+ имя контейнера вместо имени pem файла. Если сертификат установлен в хранилище КриптоПро, то можно также попробовать указывать отпечаток или CN. Соответственно есть сомнение в нужности указания пароля - КриптоПро обычно не принимает пароль от модуля и запрашивает пароль контейнера в своем интерфейсе (не уверен как это выглядит на *nix). Алгоритм ГОСТ 2001 поддерживается в gostengy - в этом плане пока проблемы нет. "Пока" в том смысле, что gostengy работает через криптопровайдер КриптоПро, а там гост-2001 скорее всего будет заблокирован 31 декабря 2019 года. На всякий случай можно проверить выполнены ли рекомендации по переносу даты блокировки или отключению контроля ключей (смотрите в базе знаний КриптоПро). Какие форматы приватников тогда поддерживаются? Также, не могли бы посказать, пожалуйста, как проверить верное обращение к CSP из OpenSSL? Отредактировано пользователем 6 августа 2019 г. 9:14:27(UTC)
| Причина: Не указана
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 05.08.2019(UTC) Сообщений: 65
Сказал(а) «Спасибо»: 4 раз
|
Все понял, но вот проблема с приватником Нужно каким-то образом из .pem получить .key файлы (header, masks, name и т.д.) Не подскажите, каким образом это можно сделать при помощи CryptoPro CSP? Спасибо
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 395 раз в 366 постах
|
Цитата:Нужно каким-то образом из .pem получить .key файлы (header, masks, name и т.д.) Не подскажите, каким образом это можно сделать при помощи CryptoPro CSP? Алгоритм такой: 1) в openssl зашифровать ключ по требованиям ТК26 в формат p12/pfx, с указанием алгоритмов гост. Теоретически командная строка выглядит примерно так: Код:openssl -engine gost -export -inkey seckey.pem -in cert.pem -out pkcs12.p12 -password pass:12345 -keypbe gost89 -certpbe gost89 -macalg md_gost12_512
Практически же получается определенная проблема, потому что старый криптокомовский модуль не поддерживает гост-2012, а новый модуль криптопро неизвестно прочитает ли ключ (команда из сообщения на этом форуме, мною лично не проверена). Однако у кого-то вроде как получилось, но если не получилось можно указать поддерживаемый гост-94, а на втором шаге указать параметр проигнорировать mac.
2) импортировать p12/pfx при помощи утилит p12util / certmgr в КриптоПро CSP.
Скорее всего потребуется компьютер с windows и криптопро csp для p12util. На *nix можно попробовать импортировать через свежий certmgr от криптопро, но шансы немного ниже. Код:А) p12util.x64.exe -p12tocp -rdrfolder d:\ -contname 888888 -ex -passcp 12345678 -passp12 12345678 -infile d:\privkey.p12
Б) p12util.x64.exe -p12tocp -rdrfolder d:\ -contname 888888 -ex -passcp 12345678 -passp12 12345678 -infile d:\privkey.p12 -noCPKM -noMACVerify
Подробнее про импорт и ссылка на утилиту: https://www.cryptopro.ru...aspx?g=posts&t=16062 Если все удачно получите папку с заветными файлами. Сертификат вероятно придется доустанавливать в контейнер дополнительно.
Отредактировано пользователем 6 августа 2019 г. 11:16:53(UTC)
| Причина: Не указана
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 06.05.2019(UTC) Сообщений: 9 Откуда: Москва
Сказал(а) «Спасибо»: 3 раз
|
Подскажите пожалуйста как быть в следующей ситуации:
Пытаюсь настроить nginx таким образом, чтобы на 1443 порту был один сертификат серверный, а на 2443 другой. Ключ сертификата конфигурируется директивой ssl_certificate_key, но CN у обоих сертификатов одинаковый. И они цепляют одинаковый серт. Можно ли в ssl_certificate_key подсунуть отпечаток или что-то другое?
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close