logo Наши способы организации безопасного удалённого доступа к рабочим местам и корпоративным ресурсам
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

30 Страницы«<2122232425>»
Опции
К последнему сообщению К первому непрочитанному
Offline colotiline  
#441 Оставлено : 20 сентября 2018 г. 11:54:19(UTC)
colotiline

Статус: Участник

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

Сказал(а) «Спасибо»: 5 раз
Подскажите, пожалуйста, где взять список возможных ответов для команды ниже?
Код:

openssl smime -verify -crl_check -inform DER -in /home/cms.bin -content /home/message.txt -CAfile /etc/pki/ca-trust/source/anchors/crypto-cert-combine.pem


Что есть успех понятно. Но среди неуспеха нужно выделять:

  • Невозможно проверить подпись этим сертификатом.
  • Подпись валидная, но сертификат устарел.
  • Подпись валидная, но сертификат не начал действовать (такое возможно?).
  • Подпись валидная, но СОС устарел.
Offline two_oceans  
#442 Оставлено : 20 сентября 2018 г. 12:26:41(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 929
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 58 раз
Поблагодарили: 204 раз в 192 постах
Цитата:
В bash (и вроде бы в других оболочках в Linux) отлично работают одинарные кавычки, с ними дополнительное экранирование не требуется
bash это конечно замечательно, но c openssl не так все прозрачно. Буквально на предыдущей странице gostengy не загружалась в openssl из-за неэкранированных \ в пути в файле конфигурации! Раз ни одно из значений не срабатывает, то это наводит на мысль о неверной подготовке openssl значения, передаваемого в gostengy и надо эту подготовку как-то нивелировать, чтобы в gostengy поступило верное значение. Возможно и одинарные кавычки использовать и \ проэкранировать.
Цитата:
Подпись валидная, но сертификат не начал действовать (такое возможно?).
Возможно, если на компьютере, где производится проверка, выставлено время далеко в прошлое, а в подписи не указано время подписания. Другой вариант, если время верное, подписано и проверено в день получения сертификата, но в другом часовом поясе - при этом тоже могут быть странные эффекты. Есть и другие ситуации, связанные с особенностями отсчета времени - например, секунд в минуте не всегда 60, иногда раз в полугодие 1 секунду добавляют или убирают чтобы компенсировать неравномерность движения Земли, но вероятность попасть на такую ситуацию ничтожно мала. Кроме того, у УЦ есть опция выпускать сертификаты с датой начала в будущем, но таким сертификатом будет нельзя подписать до наступления этой даты. То есть если такой сертификат использовать для подписи на компьютере с отведенной датой в будущее, то при проверке на компьютере с верной датой также возможно выявление ошибки "сертификат не начал действовать". Собственно, выявлять такую ситуацию и не нужно - просто проверить регулярно правильность установки времени на своем куомпьютере и возвращать на повторную подпись.
Цитата:
Невозможно проверить подпись этим сертификатом.
Такую ситуацию почти невозможно отличить от измененной подписи, если алгоритм сертификата подходит для алгоритма подписи. Из остальных ошибок пожалуй имеет значение устаревший CRL, это тоже можно решить регулярными обновлениями, например раз в сутки.

Отредактировано пользователем 20 сентября 2018 г. 12:37:11(UTC)  | Причина: дополнено

thanks 1 пользователь поблагодарил two_oceans за этот пост.
colotiline оставлено 20.09.2018(UTC)
Offline colotiline  
#443 Оставлено : 20 сентября 2018 г. 12:32:57(UTC)
colotiline

Статус: Участник

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

Сказал(а) «Спасибо»: 5 раз
Автор: colotiline Перейти к цитате
Подскажите, пожалуйста, где взять список возможных ответов для команды ниже?
Код:

openssl smime -verify -crl_check -inform DER -in /home/cms.bin -content /home/message.txt -CAfile /etc/pki/ca-trust/source/anchors/crypto-cert-combine.pem


Что есть успех понятно. Но среди неуспеха нужно выделять:

  • Невозможно проверить подпись этим сертификатом.
  • Подпись валидная, но сертификат устарел.
  • Подпись валидная, но сертификат не начал действовать (такое возможно?).
  • Подпись валидная, но СОС устарел.


Невозможно проверить подпись этим сертификатом
Verification failure
139793328756624:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:336:Verify error:unable to get local issuer certificate

Подпись валидная, но сертификат устарел
?

Подпись валидная, но сертификат не начал действовать
?

Подпись валидная, но СОС устарел
Verification failure
140363354548112:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:336:Verify error:CRL has expired
Offline colotiline  
#444 Оставлено : 20 сентября 2018 г. 12:35:44(UTC)
colotiline

Статус: Участник

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

Сказал(а) «Спасибо»: 5 раз
Автор: two_oceans Перейти к цитате
Цитата:
В bash (и вроде бы в других оболочках в Linux) отлично работают одинарные кавычки, с ними дополнительное экранирование не требуется
bash это конечно замечательно, но c openssl не так все прозрачно. Буквально на предыдущей странице gostengy не загружалась в openssl из-за неэкранированных \ в пути в файле конфигурации! Раз ни одно из значений не срабатывает, то это наводит на мысль о неверной подготовке openssl значения, передаваемого в gostengy и надо эту подготовку как-то нивелировать, чтобы в gostengy поступило верное значение. Возможно и одинарные кавычки использовать и \ проэкранировать.
Цитата:
Подпись валидная, но сертификат не начал действовать (такое возможно?).
Возможно, если на компьютере, где производится проверка, выставлено время далеко в прошлое, а в подписи не указано время подписания. Другой вариант, если время верное, подписано и проверено в день получения сертификата, но в другом часовом поясе - при этом тоже могут быть странные эффекты. Есть и другие ситуации, связанные с особенностями отсчета времени - например, секунд в минуте не всегда 60, иногда раз в полугодие 1 секунду добавляют или убирают чтобы компенсировать неравномерность движения Земли, но вероятность попасть на такую ситуацию ничтожно мала. Кроме того, у УЦ есть опция выпускать сертификаты с датой начала в будущем, но таким сертификатом будет нельзя подписать до наступления этой даты. То есть если такой сертификат использовать для подписи на компьютере с отведенной датой в будущее, то при проверке на компьютере с верной датой также возможно выявление ошибки "сертификат не начал действовать".


Мне бы сообщение от OpenSSL получить, чтобы его потом скармливать валидатору и понимать, что делать с такой подписью. Пока не могу этого сделать, так как openssl в докере, в нём время нельзя менять, а на хосте нет прав на изменение времени. В целом, если никто не ответит, разберусь позже дома.

За описание ситуаций по "не начал действовать" большое спасибо. :)
Offline dmitryp  
#445 Оставлено : 20 сентября 2018 г. 13:55:25(UTC)
dmitryp

Статус: Участник

Группы: Участники
Зарегистрирован: 11.07.2017(UTC)
Сообщений: 28
Российская Федерация

Сказал(а) «Спасибо»: 3 раз
Автор: two_oceans Перейти к цитате
Цитата:
В bash (и вроде бы в других оболочках в Linux) отлично работают одинарные кавычки, с ними дополнительное экранирование не требуется
bash это конечно замечательно, но c openssl не так все прозрачно. Буквально на предыдущей странице gostengy не загружалась в openssl из-за неэкранированных \ в пути в файле конфигурации! Раз ни одно из значений не срабатывает, то это наводит на мысль о неверной подготовке openssl значения, передаваемого в gostengy и надо эту подготовку как-то нивелировать, чтобы в gostengy поступило верное значение. Возможно и одинарные кавычки использовать и \ проэкранировать.


Вот воспроизводимый тест-кейс: https://gist.github.com/...e77b9b968267bd3c355baa8f . Скриптом создаю контейнер "foo" (CN=bar), и прогоняю варианты с/без экранированием обратного слеша, двоеточия, пробелов, с/без одинарными кавычками, с/без префиксом "c:", со всеми формами во всех комбинациях. Из порядка 500 полученных вариантов ни один не сработал.

Отредактировано пользователем 20 сентября 2018 г. 13:56:14(UTC)  | Причина: Не указана

Offline Дмитрий Пичулин  
#446 Оставлено : 20 сентября 2018 г. 14:55:17(UTC)
Дмитрий Пичулин

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

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 931
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 22 раз
Поблагодарили: 145 раз в 124 постах
Автор: dmitryp Перейти к цитате
Попробовал (безрезультатно) следующие варианты:

В логе OpenSSL должна быть соответствующая ошибка со словами "gng_support_getuserkey", если её нет, то что-то идёт не так и до вызова нашей функции просто не доходит.

Знания в базе знаний, поддержка в техподдержке
Offline dmitryp  
#447 Оставлено : 21 сентября 2018 г. 5:48:34(UTC)
dmitryp

Статус: Участник

Группы: Участники
Зарегистрирован: 11.07.2017(UTC)
Сообщений: 28
Российская Федерация

Сказал(а) «Спасибо»: 3 раз
Автор: Дмитрий Пичулин Перейти к цитате
Автор: dmitryp Перейти к цитате
Попробовал (безрезультатно) следующие варианты:

В логе OpenSSL должна быть соответствующая ошибка со словами "gng_support_getuserkey", если её нет, то что-то идёт не так и до вызова нашей функции просто не доходит.



Такой ошибки там нет:
Код:
engine "gostengy" set.
cannot load signing key file from engine
139983316783296:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:crypto/engine/eng_pkey.c:78:
unable to load signing key file
Offline Дмитрий Пичулин  
#448 Оставлено : 21 сентября 2018 г. 8:50:27(UTC)
Дмитрий Пичулин

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

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 931
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 22 раз
Поблагодарили: 145 раз в 124 постах
Автор: dmitryp Перейти к цитате
Автор: Дмитрий Пичулин Перейти к цитате
Автор: dmitryp Перейти к цитате
Попробовал (безрезультатно) следующие варианты:

В логе OpenSSL должна быть соответствующая ошибка со словами "gng_support_getuserkey", если её нет, то что-то идёт не так и до вызова нашей функции просто не доходит.



Такой ошибки там нет:
Код:
engine "gostengy" set.
cannot load signing key file from engine
139983316783296:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:crypto/engine/eng_pkey.c:78:
unable to load signing key file

Да, в логе не видно нашего вызова, значит ошибка до него. Проверим, изучим.

Знания в базе знаний, поддержка в техподдержке
Offline two_oceans  
#449 Оставлено : 21 сентября 2018 г. 10:19:54(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 929
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 58 раз
Поблагодарили: 204 раз в 192 постах
Цитата:
В логе OpenSSL должна быть соответствующая ошибка со словами "gng_support_getuserkey", если её нет, то что-то идёт не так и до вызова нашей функции просто не доходит.
Как я понимаю был процитирован вывод на консоль... а где смотреть лог openssl если понадобится не подскажете? Наверно его надо как-то включить? попробовал искать в интернете, но все выдачи поиска забиты пересказами как установить openssl и как сгенерировать самоподписанный сертификат.
Offline VictorFrom  
#450 Оставлено : 21 сентября 2018 г. 16:27:41(UTC)
VictorFrom

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

Группы: Участники
Зарегистрирован: 13.09.2018(UTC)
Сообщений: 36
Российская Федерация

Сказал(а) «Спасибо»: 9 раз
Прошу прощения, что я влезаю в эту напряженную дискуссию, но хочется окончательно удостовериться.

Правильно ли я понимаю, что несмотря на то, что используется openssl, все равно она работает с CryptoproCSP
и для работы по ГОСТ 2012 нужно его устанавливать (CryptoproCSP). И нет никакой реализации ГОСТ в openssl,
которая бы работала без CryptoproCSP.

Тогда в чем должен быть выигыш от использования openssl в командной строке, если есть родная утилита cryptcp,
которая может тоже выполнять подпись и шифрование? А для работы с сертификатами - certmgr.

Offline Ефремов Степан  
#451 Оставлено : 21 сентября 2018 г. 17:59:58(UTC)
Ефремов Степан

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

Группы: Участники
Зарегистрирован: 31.08.2017(UTC)
Сообщений: 20
Российская Федерация

Поблагодарили: 6 раз в 6 постах
Автор: dmitryp Перейти к цитате
Автор: Дмитрий Пичулин Перейти к цитате
Автор: dmitryp Перейти к цитате
Попробовал (безрезультатно) следующие варианты:

В логе OpenSSL должна быть соответствующая ошибка со словами "gng_support_getuserkey", если её нет, то что-то идёт не так и до вызова нашей функции просто не доходит.



Такой ошибки там нет:
Код:
engine "gostengy" set.
cannot load signing key file from engine
139983316783296:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:crypto/engine/eng_pkey.c:78:
unable to load signing key file



Openssl-1.1.0 c указанием имени контейнера в "-inkey" работает:

- Ubuntu 16.04
- CSP (Type:80) 4.0.9944 (Xenocrates) KC2
- Пакеты cprocsp-cpopenssl-110-* 5.0 (https://update.cryptopro.ru/support/nginx-gost/bin/archives/173647/)
(gostengy) CryptoPro GostEngy ($Revision: 168568 $)


Генерация сертификата с ключами:
Код:
/opt/cprocsp/bin/amd64/cryptcp -creatcert -provtype 80 -rdn "CN=t2012" -cont "\\\\.\\HDIMAGE\\t2012cont" -certusage 1.3.6.1.5.5.7.3.1 -ku -du -ex -ca http://cryptopro.ru/certsrv

CryptCP 4.0 (c) "Crypto-Pro", 2002-2017.
Command prompt Utility for file signature and encryption.
Creating request...
CryptoPro CSP: Set password on produced container "t2012cont".
Password:
Retype password:
Sending request to CA...
Installing certificate...
Certificate is installed.
[ReturnCode: 0]



Экспорт сертификата:
Код:
/opt/cprocsp/bin/amd64/certmgr -export -dn CN=t2012 -dest ./t2012.der
Certmgr 1.1 (c) "CryptoPro",  2007-2010.
program for managing certificates, CRLs and stores

Exporting: 
=============================================================================
1-------
Issuer              : E=support@cryptopro.ru, C=RU, L=Moscow, O=CRYPTO-PRO LLC, CN=CRYPTO-PRO Test Center 2
Subject             : CN=t2012
Serial              : 0x12002D595C78349DA70081580A0000002D595C
SHA1 Hash           : a0138e8cb88d522943bb4e0a7310b57f7e522a1e
SubjKeyID           : d9f85a8042a5d0d972883393612a26147e626178
Signature Algorithm : ГОСТ Р 34.11/34.10-2001
PublicKey Algorithm : ГОСТ Р 34.10-2012 (512 bits)
Not valid before    : 21/09/2018  14:16:38 UTC
Not valid after     : 21/12/2018  14:26:38 UTC
PrivateKey Link     : Yes                 
Container           : HDIMAGE\\t2012con.000\DA37
Provider Name       : Crypto-Pro GOST R 34.10-2012 KC2 CSP
Provider Info       : ProvType: 80, KeySpec: 2, Flags: 0x0
CA cert URL         : http://testca.cryptopro.ru/CertEnroll/test-ca-2014_CRYPTO-PRO%20Test%20Center%202.crt
OCSP URL            : http://testca.cryptopro.ru/ocsp/ocsp.srf
CDP                 : http://testca.cryptopro.ru/CertEnroll/CRYPTO-PRO%20Test%20Center%202.crl
Extended Key Usage  : 1.3.6.1.5.5.7.3.1
=============================================================================
Export complete

[ErrorCode: 0x00000000]



Конвертация в PEM(base64):
Код:
/opt/cprocsp/cp-openssl-1.1.0/bin/amd64/openssl x509 -in ./t2012.der -inform DER -out ./t2012.pem -outform PEM



Подпись:
Код:
/opt/cprocsp/cp-openssl-1.1.0/bin/amd64/openssl cms -sign -engine gostengy -keyform ENGINE -inkey c:t2012cont -in for_sign.txt -binary -out content.sign -outform DER -signer ./t2012.pem

engine "gostengy" set.



Подпись (2 вариант):
Код:
/opt/cprocsp/cp-openssl-1.1.0/bin/amd64/openssl cms -sign -engine gostengy -keyform ENGINE -inkey c:"\\\\.\\HDIMAGE\\t2012cont" -in for_sign.txt -binary -out content.sign -outform PEM -signer ./t2012.pem

engine "gostengy" set.

Техническая поддержка здесь.
База знаний здесь.
Offline two_oceans  
#452 Оставлено : 24 сентября 2018 г. 6:16:47(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 929
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 58 раз
Поблагодарили: 204 раз в 192 постах
Автор: VictorFrom Перейти к цитате
Правильно ли я понимаю, что несмотря на то, что используется openssl, все равно она работает с Cryptopro CSP и для работы по ГОСТ 2012 нужно его устанавливать (Cryptopro CSP). И нет никакой реализации ГОСТ в openssl, которая бы работала без Cryptopro CSP.
Модули gost_capi и gostengy работают только с КриптоПро CSP, все верно. В чистой openssl с некоторого момента нет реализации ГОСТ, старый код в openssl 1.0 не поддерживает гост-2012 и изменения структуры openssl, его исключили, все верно. Есть другой отечественный криптопровайдер сертифицировавший ветку openssl с реализацией ГОСТ. Такая версия работает без КриптоПро, но платная.
Автор: VictorFrom Перейти к цитате
Тогда в чем должен быть выигыш от использования openssl в командной строке, если есть родная утилита cryptcp, которая может тоже выполнять подпись и шифрование? А для работы с сертификатами - certmgr.
Вот у меня почти всегда всегда возникает этот же вопрос. На текущий момент выигрыш в основном для кроссплатформанных приложений изначально построенных на библиотеках openssl (которых тьма), а также для создания внутреннего неаккредитованного УЦ предприятия.

Offline dmitryp  
#453 Оставлено : 25 сентября 2018 г. 11:06:41(UTC)
dmitryp

Статус: Участник

Группы: Участники
Зарегистрирован: 11.07.2017(UTC)
Сообщений: 28
Российская Федерация

Сказал(а) «Спасибо»: 3 раз
Автор: Ефремов Степан Перейти к цитате
Openssl-1.1.0 c указанием имени контейнера в "-inkey" работает:


Огромное спасибо, с помощью вашего примера смог нащупать решение. Дело было в старой версии библиотеки cprocsp-cpopenssl-110-*. При переходе на 5.0 (https://update.cryptopro.ru/support/nginx-gost/bin/180423/) контейнер действительно корректно обнаруживается. Приведённый выше скрипт корректно находит контейнер по разным вариантам наименования (от дружественного до полного) - и, кстати, дополнительное экранирование не потребовалось (по крайней мере для простого имени контейнера). В общем, буду полагаться на то что от различия версий openssl-модуля (5.0) и самой CSP (4.0) ничего сломаться не должно.

Итого оба моих вопроса решены. Ещё раз спасибо.
Offline two_oceans  
#454 Оставлено : 4 декабря 2018 г. 11:14:24(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 929
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 58 раз
Поблагодарили: 204 раз в 192 постах
Добрый день.
У меня возникла проблема с новыми версиями engine - когда я пытаюсь указать закрытый ключ алгоритма ГОСТ-2001 из файла в формате PEM 1) c gost_capi на openssl 1.0.2h; 2) с gostengy на 1.1.0j, то получаю ошибку что невозможно считать закрытый ключ. При этом со старым (предположительно криптокомовским) gost engine который шел с версией openssl 1.0.2h на openssl 1.0.2h ключ прекрасно читается. Поэтому нет сомнений, что дело в новой версии engine, а не в испорченном файле или неверно указанном пути к файлу - проверяю одним пакетным файлом только с разными путями openssl и включая-выключая engine. Несколько помню с gost_capi прошлогодней сборки тоже не было проблем. Первый вопрос: действительно ли новые версии не поддерживают ключи ГОСТ-2001 из файла? Или надо что-то еще с этим сделать? Файл содержит ключевую пару - и открытый ключ в формате PEM и незашифрованный закрытый ключ в формате PEM с соответствующими ограничителями. (используется для перегенерации сертификата на внутреннем УЦ) Навскидку не по формату только наличие переводов строки с кодом 13 в записи закрытого ключа.

Сам ключ пару лет назад был сгенерен в криптопро потом вытащен в формат openssl, но сейчас я уже не могу найти исходный контейнер. Есть еще один ключ ГОСТ-2001 в подобной ситуации, у остальных нашлись исходные контейнеры. Перспектива переключаться каждый раз на 1.0.2h и исходный engine что-то меня не радует. Поэтому второй вопрос: как можно затолкать ключ из PEM обратно в контейнер КриптоПро для работы через новые engine. Пробовал через импорт PFX, но неудачно - ни p12utility ни стандартный импорт не понимают формат сделанный openssl. Поискал по форуму, но без особого успеха - все соглашаются что параметры по умолчанию не поддерживаются, но из двух ссылок на нормативные требования ТК 26 одна нерабочая, вторая предлагает использовать мак гост2012. Нельзя ли уточнить, какие именно значения -keypbe -certpbe -macalg может быть еще каких параметров должны быть указаны для корректного экспорта pfx с ключом ГОСТ-2001. От старой библиотеки немного слишком требовать защиты pfx c использованием мак гост-2012, в новой ключ не читается. Сейчас из-за нехватки времени я наверно просто перегенерирую второй ключ, но хотелось бы знать как поступать в подобной ситуации.

Отредактировано пользователем 4 декабря 2018 г. 11:17:38(UTC)  | Причина: Не указана

Offline Дмитрий Пичулин  
#455 Оставлено : 4 декабря 2018 г. 11:39:52(UTC)
Дмитрий Пичулин

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

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 931
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 22 раз
Поблагодарили: 145 раз в 124 постах
Автор: two_oceans Перейти к цитате
Первый вопрос: действительно ли новые версии не поддерживают ключи ГОСТ-2001 из файла?

Наши энжины никогда не поддерживали работу с закрытым ключом из файлов, необходимы контейнеры КриптоПро.

Автор: two_oceans Перейти к цитате
Поэтому второй вопрос: как можно затолкать ключ из PEM обратно в контейнер КриптоПро для работы через новые engine.

На вопрос "как можно затолкать" ответа нет.

В настоящий момент существует стандартизированный способ транспортного представления закрытого ключа ГОСТ, это формат PKCS12 от ТК26: http://wwwold.tc26.ru/me...ddition_to_PKCS12_v2.pdf

Если ваша библиотека поддерживает экспорт в подобном формате, то импортировать контейнер можно следующей командой:

Код:
/opt/cprocsp/bin/amd64/certmgr -inst -pfx -pin 123456 -file /usr/data/certkey.pfx


Знания в базе знаний, поддержка в техподдержке
thanks 1 пользователь поблагодарил Дмитрий Пичулин за этот пост.
two_oceans оставлено 04.12.2018(UTC)
Offline two_oceans  
#456 Оставлено : 4 декабря 2018 г. 13:04:13(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 929
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 58 раз
Поблагодарили: 204 раз в 192 постах
Автор: Дмитрий Пичулин Перейти к цитате
Автор: two_oceans Перейти к цитате
Первый вопрос: действительно ли новые версии не поддерживают ключи ГОСТ-2001 из файла?
Наши энжины никогда не поддерживали работу с закрытым ключом из файлов, необходимы контейнеры КриптоПро.
Спасибо за оперативный и исчерпывающий ответ. Видимо мне показалось, что прошлогодняя gost_capi "не ругалась" на данный ключ, найду и перепроверю.
Автор: Дмитрий Пичулин Перейти к цитате
Автор: two_oceans Перейти к цитате
Поэтому второй вопрос: как можно затолкать ключ из PEM обратно в контейнер КриптоПро для работы через новые engine.

На вопрос "как можно затолкать" ответа нет.
Согласен, некорректная формулировка.
Автор: Дмитрий Пичулин Перейти к цитате
В настоящий момент существует стандартизированный способ транспортного представления закрытого ключа ГОСТ, это формат PKCS12 от ТК26: http://wwwold.tc26.ru/me...ddition_to_PKCS12_v2.pdf
Если ваша библиотека поддерживает экспорт в подобном формате, то импортировать контейнер можно следующей командой:
Код:
/opt/cprocsp/bin/amd64/certmgr -inst -pfx -pin 123456 -file /usr/data/certkey.pfx
Спасибо за информацию. Опять же по ссылке описание транспортного представления ГОСТ-2012, а не ГОСТ-2001. Вероятность поддержки именно ГОСТ-2012 той библиотекой нулевая и хотелось бы узнать скорее об импорте более старой версии представления для ГОСТ-2001.

Для ГОСТ-2012 проблема не стоит, потому что: 1) я не знаю как "вытащить" ключ ГОСТ-2012 из контейнера; 2) с учетом поддержки контейнера энжинами мне теперь и не нужно "вытаскивать". Соответственно мне скорее всего и не потребуется конвертировать обратно в формат контейнера, но на всякий случай приму к сведению, спасибо.

В итоге, правильно ли я понимаю, что нужно реализовать преобразование ключа PEM в транспортный формат ГОСТ-2012 PKCS12 некими сторонними средствами самостоятельно потому что openssl этого не сможет сделать? Замечательно, тогда еще два вопроса для определения с какой стороны взяться: 1) где можно посмотреть соответствие между оидами и текстовыми обозначениями алгоритмов в openssl; 2) поддерживаются ли все алгоритмы упомянутые в транспортном формате ГОСТ-2012 в Криптопро CSP 4.0 через CryptoAPI?

Отредактировано пользователем 4 декабря 2018 г. 13:06:38(UTC)  | Причина: Не указана

Offline Дмитрий Пичулин  
#457 Оставлено : 4 декабря 2018 г. 13:13:51(UTC)
Дмитрий Пичулин

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

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 931
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 22 раз
Поблагодарили: 145 раз в 124 постах
Автор: two_oceans Перейти к цитате
В итоге, правильно ли я понимаю, что нужно реализовать преобразование ключа PEM в транспортный формат ГОСТ-2012 PKCS12 некими сторонними средствами самостоятельно потому что openssl этого не сможет сделать? Замечательно, тогда еще два вопроса для определения с какой стороны взяться: 1) где можно посмотреть соответствие между оидами и текстовыми обозначениями алгоритмов в openssl; 2) поддерживаются ли все алгоритмы упомянутые в транспортном формате ГОСТ-2012 в Криптопро CSP 4.0 через CryptoAPI?

Создавайте новую тему.
Знания в базе знаний, поддержка в техподдержке
Offline dmitry lavrov  
#458 Оставлено : 4 декабря 2018 г. 16:58:03(UTC)
dmitry lavrov

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

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

Поблагодарили: 1 раз в 1 постах
На сервере с настроенным nginx+gostengy+ГОСТ2012 сертификат сервера - периодически (примерно через месяц работы) nginx начинает сбрасывать подключения
В логе при этом ошибка:
2018/12/03 20:58:51 [crit] 7884#7884: *134341 SSL_do_handshake() failed (SSL: error:8001B035:lib(128):gng_keyhandle_getset:GNG_ERR_EXPORT_IMPOR
T error:1419D093:SSL routines:tls_process_cke_gost:decryption failed) while SSL handshaking, client: 111.111.111.111, server: 0.0.0.0:443

Нашел похожую ошибку в мэйллисте Nginx - авторы говорят пишите авторам gostengy %) https://forum.nginx.org/...281647,281647#msg-281647

Помогает service nginx restart

Помогите пожалуйста решить эту проблему более профессионально. :)

Installed Packages
cprocsp-cpopenssl-110-64.x86_64 5.0.11099-5 installed
cprocsp-cpopenssl-110-base.noarch 5.0.11099-5 installed
cprocsp-cpopenssl-110-devel.noarch 5.0.11099-5 installed
cprocsp-cpopenssl-110-gost-64.x86_64 5.0.11099-5 installed
cprocsp-curl-64.x86_64 4.0.9944-5 installed

cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)

Отредактировано пользователем 4 декабря 2018 г. 16:59:21(UTC)  | Причина: Не указана

thanks 1 пользователь поблагодарил dmitry lavrov за этот пост.
Дмитрий Пичулин оставлено 04.12.2018(UTC)
Offline Дмитрий Пичулин  
#459 Оставлено : 4 декабря 2018 г. 17:25:55(UTC)
Дмитрий Пичулин

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

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 931
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 22 раз
Поблагодарили: 145 раз в 124 постах
Автор: dmitry lavrov Перейти к цитате
На сервере с настроенным nginx+gostengy+ГОСТ2012 сертификат сервера - периодически (примерно через месяц работы) nginx начинает сбрасывать подключения
В логе при этом ошибка:
2018/12/03 20:58:51 [crit] 7884#7884: *134341 SSL_do_handshake() failed (SSL: error:8001B035:lib(128):gng_keyhandle_getset:GNG_ERR_EXPORT_IMPOR
T error:1419D093:SSL routines:tls_process_cke_gost:decryption failed) while SSL handshaking, client: 111.111.111.111, server: 0.0.0.0:443

Нашел похожую ошибку в мэйллисте Nginx - авторы говорят пишите авторам gostengy %) https://forum.nginx.org/...281647,281647#msg-281647

Помогает service nginx restart

Помогите пожалуйста решить эту проблему более профессионально. :)

Хорошая ошибка, так глубоко мало кто смог забраться, поэтому здесь начинается серая зона.

Ошибка в том, что gostengy не может найти в своей базе данных ключ по запросу от openssl.

Ситуация такова, что openssl оперирует "голыми" ключами, это противоречит использованию ключей в CSP, поэтому мы никогда не даём openssl реальные значения ключей, но даём идентификаторы.

Время жизни идентификаторов = 10 минут с момента последнего использования.

Мы не можем контролировать использование идентификаторов (ключей) самим openssl, так как эта часть не связана с engine.

Таким образом, если openssl спустя 10 минут захочет возобновить сессию, то он может попасть в ситуацию, что ключ в базе данных gostengy уже освобождён.

Это должно решаться типичным ограничением времени жизни сессии в ssl_session_cache и ssl_session_timeout не более 10 минут.

Возможно также, что существует какой-то сценарий, который мы не предусмотрели, хотя очень старались реализовать все сценарии работы TLS.

Если ошибка сохраняется после введения ограничений на 10 минут, пришлите вашу конфигурацию и тестовый сценарий приводящий к ошибке, будем разбираться.

UPD: Нет, ошибка всё таки у нас, не предусмотрели смену ключа при переносе ключей между провайдерами, хватало на ~60 тысяч ключей... Исправляем.

Отредактировано пользователем 4 декабря 2018 г. 18:04:44(UTC)  | Причина: Не указана

Знания в базе знаний, поддержка в техподдержке
Offline dmitry lavrov  
#460 Оставлено : 4 декабря 2018 г. 17:40:30(UTC)
dmitry lavrov

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

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

Поблагодарили: 1 раз в 1 постах
Уже был установлен параметр ssl_session_timeout 5m;
Добавил ssl_session_cache off;

Будем мониторить, если ошибка повторится - обязательно сообщу.
Спасибо!

Отредактировано пользователем 4 декабря 2018 г. 17:49:30(UTC)  | Причина: Не указана

RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
30 Страницы«<2122232425>»
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.