Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Наши способы организации безопасного удалённого доступа к рабочим местам и корпоративным ресурсам
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

18 Страницы«<15161718>
Опции
К последнему сообщению К первому непрочитанному
Offline Justz  
#321 Оставлено : 27 ноября 2020 г. 13:10:46(UTC)
Justz

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

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

root@osboxes:/home/osboxes/tls# /opt/cprocsp/sbin/amd64/cpconfig -license -view
License validity:
5050010037ELQF5H28KM8E6BA
Expires: 93 day(s)
License type: Demo.


root@osboxes:/home/osboxes/tls# dpkg-query --list | grep csp
ii cprocsp-cpopenssl-110-64 5.0.11803-6 amd64 OpenSSL-110. Build 11803.
ii cprocsp-cpopenssl-110-base 5.0.11803-6 all Openssl-110 common Build 11803.
ii cprocsp-cpopenssl-110-devel 5.0.11803-6 all Openssl-110 devel Build 11803.
ii cprocsp-cpopenssl-110-gost-64 5.0.11803-6 amd64 OpenSSL-110 gostengy engine. Build 11803.
ii cprocsp-curl-64 5.0.11944-6 amd64 CryptoPro cURL shared library and application. Build 11944.
ii lsb-cprocsp-base 5.0.11944-6 all CryptoPro CSP directories and scripts. Build 11944.
ii lsb-cprocsp-ca-certs 5.0.11944-6 all CryptoPro CA certificates. Build 11944.
ii lsb-cprocsp-capilite-64 5.0.11944-6 amd64 CryptoPro CSP. CryptoAPI Lite libraries and applications. Build 11944.
ii lsb-cprocsp-kc1-64 5.0.11944-6 amd64 CryptoPro CSP KC1. Build 11944.
iU lsb-cprocsp-kc2:i386 5.0.11944-6 i386 CryptoPro CSP KC2. Build 11944.
ii lsb-cprocsp-kc2-64 5.0.11944-6 amd64 CryptoPro CSP KC2. Build 11944.
ii lsb-cprocsp-rdr-64 5.0.11944-6 amd64 CryptoPro CSP common libraries and utilities. Build 11944

Отредактировано пользователем 27 ноября 2020 г. 13:11:29(UTC)  | Причина: Не указана

Offline Ефремов Степан  
#322 Оставлено : 27 ноября 2020 г. 13:49:16(UTC)
Ефремов Степан

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

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

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 17 раз в 16 постах
Перезапустил сборку на трависе - прошла.

Это означает: либо вы что-то упустили, либо проблема в новом CSP, в чем я пока сомневаюсь.

Смущает так же эта запись: "lsb-cprocsp-kc2:i386".

Попробуйте сделать заного по инструкции. Если будет аналогичная ошибка, то можно посмотреть в syslog, может там будут подробности.
Техническая поддержка здесь.
База знаний здесь.
Offline Justz  
#323 Оставлено : 30 ноября 2020 г. 12:33:27(UTC)
Justz

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

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

Все удалось настроить, только пришлось выпускать и подписывать сертификат ручками загружая запрос на уц непосредственно. Дальше проделывать все процедуры написанные пошагово.

Я допускаю что где-то что-то делал не так, но ошибка была после штатной отработки скрипта. Плюс запрос на новый сертификат с установленной и сконфигурированной системой которая работала месяц назад тоже вывалился с ошибкой про CURL, и там я точно ничего не переделывал (хотя могло и автоматом что-то обновиться).
Offline Ефремов Степан  
#324 Оставлено : 30 ноября 2020 г. 14:34:35(UTC)
Ефремов Степан

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

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

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 17 раз в 16 постах
Автор: Justz Перейти к цитате
Все удалось настроить, только пришлось выпускать и подписывать сертификат ручками загружая запрос на уц непосредственно. Дальше проделывать все процедуры написанные пошагово.

Я допускаю что где-то что-то делал не так, но ошибка была после штатной отработки скрипта. Плюс запрос на новый сертификат с установленной и сконфигурированной системой которая работала месяц назад тоже вывалился с ошибкой про CURL, и там я точно ничего не переделывал (хотя могло и автоматом что-то обновиться).


Проверил с версией CSP 11944-6 как у вас - работает.

Может есть что-нибудь подозрительное в /var/log/syslog после получения ошибки про CURL при отправке запроса?
Пока не воспроизводится.
Техническая поддержка здесь.
База знаний здесь.
Offline alex_nur  
#325 Оставлено : 4 декабря 2020 г. 9:59:42(UTC)
alex_nur

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

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

Сказал(а) «Спасибо»: 2 раз
Добрый день. Получилось у меня запустить через ГОСТ.

Проблема в том, что все работает из под пользователя root (в /etc/nginx/nginx.conf указано user=root;)
При указании пользователя www-data в /etc/nginx/nginx.conf и запуске из под root:
# nginx
Nginx спрашивает пинкод, ввожу, запускается.
Но ГОСТ-шифрование не работает. Ошибки SSL выдаются.

Т.е. www-data не видит ключей. Контейнер с 6 файлами я готовил под пользователем root.

Тогда я удалил контейнер, и создал каталог apiporta.000 в /var/opt/cprocsp/keys/www-data/apiporta.000. В этот каталог я скопировал 6 файлов *.key.
Задалразрешения и владельца:
# chmod -R 777 /var/opt/cprocsp/keys/www-data
# chown www-data:www-data /var/opt/cprocsp/keys/www-data

Под пользователем www-data:
$ /opt/cprocsp/bin/amd64/csptest -keyset -enum_cont -verifycontext -fqcn
видно мой контейнер с ключами.

Далее все операции по импорту сертификата в закрытый контейнер выполнял под пользователем www-data (предварительно разрешив ему использовать оболочку /bin/bash), таким же образом когда выполнял под пользователем root (когда ГОСТ заработал, но под root).

Ошибок не возникало.
Однако при попытке запуска nginx (в файле конфигурации nginx указан пользователь www-data)
# nginx
Ошибка: nginx: [emerg] cannot load certificate key "engine:gostengy:apiportal.srvuapp03.ygd.gazprom.ru": ENGINE_load_private_key() failed (SSL: error:26096080:engine routines:ENGINE_load_private_key:failed loading private key)

Причем смена пользователя на root в конфигурации nginx дела не меняет.
При запуске приложения nginx находясь под root, логично, что пользователю root ничего не известно о ключах для пользователя www-data.

Каким образом установить сертификат в закрытый контейнер с ключами пользователя root, чтобы и пользователь www-data мог иметь к ним доступ?
Дать права на чтение группе www-data и сделать символьную ссылку на каталог контейнера?



Offline pd  
#326 Оставлено : 4 декабря 2020 г. 11:06:35(UTC)
pd

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

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

Сказал(а) «Спасибо»: 27 раз
Поблагодарили: 178 раз в 154 постах
Автор: alex_nur Перейти к цитате
Добрый день. Получилось у меня запустить через ГОСТ.

Проблема в том, что все работает из под пользователя root (в /etc/nginx/nginx.conf указано user=root;)
При указании пользователя www-data в /etc/nginx/nginx.conf и запуске из под root:
# nginx
Nginx спрашивает пинкод, ввожу, запускается.
Но ГОСТ-шифрование не работает. Ошибки SSL выдаются.

Т.е. www-data не видит ключей. Контейнер с 6 файлами я готовил под пользователем root.

Тогда я удалил контейнер, и создал каталог apiporta.000 в /var/opt/cprocsp/keys/www-data/apiporta.000. В этот каталог я скопировал 6 файлов *.key.
Задалразрешения и владельца:
# chmod -R 777 /var/opt/cprocsp/keys/www-data
# chown www-data:www-data /var/opt/cprocsp/keys/www-data

Под пользователем www-data:
$ /opt/cprocsp/bin/amd64/csptest -keyset -enum_cont -verifycontext -fqcn
видно мой контейнер с ключами.

Далее все операции по импорту сертификата в закрытый контейнер выполнял под пользователем www-data (предварительно разрешив ему использовать оболочку /bin/bash), таким же образом когда выполнял под пользователем root (когда ГОСТ заработал, но под root).

Ошибок не возникало.
Однако при попытке запуска nginx (в файле конфигурации nginx указан пользователь www-data)
# nginx
Ошибка: nginx: [emerg] cannot load certificate key "engine:gostengy:apiportal.srvuapp03.ygd.gazprom.ru": ENGINE_load_private_key() failed (SSL: error:26096080:engine routines:ENGINE_load_private_key:failed loading private key)

Причем смена пользователя на root в конфигурации nginx дела не меняет.
При запуске приложения nginx находясь под root, логично, что пользователю root ничего не известно о ключах для пользователя www-data.

Каким образом установить сертификат в закрытый контейнер с ключами пользователя root, чтобы и пользователь www-data мог иметь к ним доступ?
Дать права на чтение группе www-data и сделать символьную ссылку на каталог контейнера?

Если всё работает от рута, то можно, например, терминировать трафик на данном экземпляре nginx и делать proxy_pass на nginx от www-data.

В FAQ всегда были слова, что пользователь master и child процессов должен быть один и тот же.

То есть, если вы хотите работать от www-data, то запускать тоже следует от www-data, такие ограничения.
Знания в базе знаний, поддержка в техподдержке
Offline alex_nur  
#327 Оставлено : 4 декабря 2020 г. 13:25:05(UTC)
alex_nur

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

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

Сказал(а) «Спасибо»: 2 раз
Был готовый unit systemd от прежнего nginx, который был ранее установлен из репозитория ОС (astra linux).
Хотелось его использовать.
Была проблема - требовался пинкод.
Правки юнита с добавлением /bin/bash -c '/echo 'пинкод' | nginx .......
к результату не привели, т.к. как я не пробовал, всегда была какая-то ошибка, несмотря на то, что если напрямую из консоли таким образом задать пинкод из консоли - все работало, без вопросов о вводе пинкода.

Решение: разместил информацию о пинкоде в /var/opt/cprocsp/users/root/local.ini

Думал, что это решит проблему. Проблему запуска через systemd это решило. Но опять же, работоспособность ГОСТа только в случае если в конфигурации nginx указан пользователь root.

Пробовал также в самом unit'е nginx.service указать
user=www-data

Веб-сервер запускается, виртуальные хосты, использующие сертификаты RSA - работают. ГОСТ - не работает.
И такие ошибки:
дек 04 15:17:38 srvuapp03 nginx[43507]: <capi20>CertGetCertificateContextProperty!failed: LastError = 0x80092004
дек 04 15:17:38 srvuapp03 nginx[43507]: <capi20>CertGetCertificateContextProperty!failed: LastError = 0x80092004

Пробовал также запустить прямо от www-data.
Получаю сообщение об ошибке:
nginx: [emerg] cannot load certificate key "engine:gostengy:apiportal.srvuapp03.ygd.gazprom.ru": ENGINE_load_private_key() failed (SSL: error:26096080:engine routines:ENGINE_load_private_key:failed loading private key)

Т.е. мне надо для www-data контейнер создать, т.к. я создал для root. Возможно ли создать два одинаковых контейнера для разных пользователей?
Offline pd  
#328 Оставлено : 4 декабря 2020 г. 14:04:24(UTC)
pd

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

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

Сказал(а) «Спасибо»: 27 раз
Поблагодарили: 178 раз в 154 постах
Автор: alex_nur Перейти к цитате
Т.е. мне надо для www-data контейнер создать, т.к. я создал для root. Возможно ли создать два одинаковых контейнера для разных пользователей?

Как вам удобнее, но nginx должен запускаться и работать от одного и того же пользователя (на котором ключи и сертификаты), если хотите использовать gostengy.

Отредактировано пользователем 4 декабря 2020 г. 14:05:00(UTC)  | Причина: Не указана

Знания в базе знаний, поддержка в техподдержке
thanks 1 пользователь поблагодарил pd за этот пост.
alex_nur оставлено 04.12.2020(UTC)
Offline alex_nur  
#329 Оставлено : 4 декабря 2020 г. 14:55:33(UTC)
alex_nur

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

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

Сказал(а) «Спасибо»: 2 раз
Автор: pd Перейти к цитате
Автор: alex_nur Перейти к цитате
Т.е. мне надо для www-data контейнер создать, т.к. я создал для root. Возможно ли создать два одинаковых контейнера для разных пользователей?

Как вам удобнее, но nginx должен запускаться и работать от одного и того же пользователя (на котором ключи и сертификаты), если хотите использовать gostengy.


Установил таким же образом сертификат и контейнер для пользователя www-data.
В итоге, пришлось еще всем другим виртуальным хостам дать доступ на чтение ключей RSA, т.к. процесс теперь стартует от имени www-data, а не root.

И кульминация:
www-data@srvuapp03:/usr/sbin$ ./nginx
nginx: [warn] the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:1
Crypto-Pro GOST R 34.10-2012 KC2 Strong CSP requests password
Type password:
nginx: [emerg] bind() to 0.0.0.0:443 failed (13: Permission denied)

Вспомнилось, что однажды я сталкивался с таким случаем. Не может пользователь отличный от root создавать сокеты на системных портах - до 1024.

Доступ к другим ключам для пользователя www-data - тоже сомнительная безопасность.
В итоге имеем безопасный ГОСТ, и уменьшение безопасности в другом.

Есть идеи как запустить процесс, запускающий сокет на 443 порту не из под root?
Offline pd  
#330 Оставлено : 4 декабря 2020 г. 15:01:13(UTC)
pd

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

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

Сказал(а) «Спасибо»: 27 раз
Поблагодарили: 178 раз в 154 постах
Автор: alex_nur Перейти к цитате
В итоге имеем безопасный ГОСТ, и уменьшение безопасности в другом.

Есть идеи как запустить процесс, запускающий сокет на 443 порту не из под root?

Вам предложили терминировать TLS трафик отдельным nginx от рута и делать proxy_pass на остальные бэкенды.

Мы не запрещаем экспериментальных конфигураций, но это уже упражнения для самостоятельного освоения.


Знания в базе знаний, поддержка в техподдержке
Offline alex_nur  
#331 Оставлено : 7 декабря 2020 г. 12:47:30(UTC)
alex_nur

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

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

Сказал(а) «Спасибо»: 2 раз
И еще проблема появилась.
Необходимо к хосту с nginx ГОСТ (настроенному по инструкции в этой теме), с другой машины устанавливать HTTPS соединение из приложения на net core (HttpClient). Если использовать сертификат RSA - проблем нет, связь есть. При попытке подключиться к ГОСТовой машине выдается:

root@srvuappdev:/var/www/app# /opt/core/ASP.NET_Core_Runtime3.1.8/dotnet /var/www/app/app.dll
*** Error in `/opt/core/ASP.NET_Core_Runtime3.1.8/dotnet': double free or corruption (fasttop): 0x00007b6f2008cf60 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x70bfb)[0x7b74188f0bfb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76fc6)[0x7b74188f6fc6]
/lib/x86_64-linux-gnu/libc.so.6(+0x7780e)[0x7b74188f780e]
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(EVP_MD_CTX_reset+0x89)[0x7b6f44caad39]
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(EVP_MD_CTX_free+0x9)[0x7b6f44caada9]
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(EVP_DigestSignFinal+0x115)[0x7b6f44cbea75]
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(+0x18756d)[0x7b6f44cc756d]
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1(+0x1877e5)[0x7b6f44cc77e5]
/usr/lib/x86_64-linux-gnu/libssl.so.1.1(+0x5f465)[0x7b6f45087465]
/usr/lib/x86_64-linux-gnu/libssl.so.1.1(+0x60179)[0x7b6f45088179]
/usr/lib/x86_64-linux-gnu/libssl.so.1.1(+0x2bf0f)[0x7b6f45053f0f]
/usr/lib/x86_64-linux-gnu/libssl.so.1.1(+0x513a2)[0x7b6f450793a2]
/usr/lib/x86_64-linux-gnu/libssl.so.1.1(+0x51515)[0x7b6f45079515]
/usr/lib/x86_64-linux-gnu/libssl.so.1.1(+0x4bd7d)[0x7b6f45073d7d]
/usr/lib/x86_64-linux-gnu/libssl.so.1.1(SSL_do_handshake+0x54)[0x7b6f45060784]
[0x7b73a29ec4f6]
======= Memory map: ========
00400000-00411000 r-xp 00000000 08:02 925910 /opt/core/ASP.NET_Core_Runtime3.1.8/dotnet
00610000-00611000 r--p 00010000 08:02 925910 /opt/core/ASP.NET_Core_Runtime3.1.8/dotnet
00611000-00612000 rw-p 00011000 08:02 925910 /opt/core/ASP.NET_Core_Runtime3.1.8/dotnet
00996000-00d36000 rw-p 00000000 00:00 0 [heap]
7b6f08000000-7b6f08021000 rw-p 00000000 00:00 0
...
7b6f448f0000-7b6f4493e000 r-xp 00000000 08:02 684272 /usr/lib/x86_64-linux-gnu/engines-1.1/gost-astra.so
7b6f4493e000-7b6f44b3d000 ---p 0004e000 08:02 684272 /usr/lib/x86_64-linux-gnu/engines-1.1/gost-astra.so
7b6f44b3d000-7b6f44b3e000 r--p 0004d000 08:02 684272 /usr/lib/x86_64-linux-gnu/engines-1.1/gost-astra.so
7b6f44b3e000-7b6f44b40000 rw-p 0004e000 08:02 684272 /usr/lib/x86_64-linux-gnu/engines-1.1/gost-astra.so
7b6f44b40000-7b6f44df1000 r-xp 00000000 08:02 666741 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7b6f44df1000-7b6f44ff1000 ---p 002b1000 08:02 666741 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7b6f44ff1000-7b6f45021000 r--p 002b1000 08:02 666741 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7b6f45021000-7b6f45023000 rw-p 002e1000 08:02 666741 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
7b6f45023000-7b6f45027000 rw-p 00000000 00:00 0
7b6f45028000-7b6f450aa000 r-xp 00000000 08:02 666742 /usr/lib/x86_64-linux-gnu/libssl.so.1.1
7b6f450aa000-7b6f452aa000 ---p 00082000 08:02 666742 /usr/lib/x86_64-linux-gnu/libssl.so.1.1
7b6f452aa000-7b6f452b3000 r--p 00082000 08:02 666742 /usr/lib/x86_64-linux-gnu/libssl.so.1.1
7b6f452b3000-7b6f452b7000 rw-p 0008b000 08:02 666742 /usr/lib/x86_64-linux-gnu/libssl.so.1.1
7b73a026a000-7b73a0270000 ---p 00000000 00:00 0 Аварийный останов

Если же такого клиента запускать с той же машины, на которой установлен nginx ГОСТ, нет никаких проблем.

На другой машине (Linux, на которой проблема) установил сертифицированную версию Крипто Про CSP 5. Не помогло.
Если запускать клиента с машины ОС Windows с установленным Крипто Про, то тоже нет проблем.

На проблемной машине запускаю браузер Chromium Gost, обращась по https к машине nginx GOST. Все хорошо, даже к сертификату ГОСТ доверие есть.

Я так понимаю, проблемная машина-клиент видит шифрование ГОСТ и пытается работать через engine gost-astra.so? Почему тогда хромиум ГОСТ работает? Или он не обращается к Крипто Про?

PS: Решено. На проблемной машине необходимо было доустановить пакеты (gostengy):
dpkg -i cprocsp-cpopenssl-110-base_5.0.11455-5_all.deb
dpkg -i cprocsp-cpopenssl-110-64_5.0.11455-5_amd64.deb

Проект запустился, однако, при вводе openssl теперь выдается:
openssl: /opt/cprocsp/cp-openssl-1.1.0/lib/amd64/libssl.so.1.1: version `OPENSSL_1_1_1' not found (required by openssl)
openssl: /opt/cprocsp/cp-openssl-1.1.0/lib/amd64/libcrypto.so.1.1: version `OPENSSL_1_1_1' not found (required by openssl)

Отредактировано пользователем 7 декабря 2020 г. 13:01:57(UTC)  | Причина: Решение

Offline pd  
#332 Оставлено : 7 декабря 2020 г. 14:13:34(UTC)
pd

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

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

Сказал(а) «Спасибо»: 27 раз
Поблагодарили: 178 раз в 154 постах
Автор: alex_nur Перейти к цитате
Проект запустился, однако, при вводе openssl теперь выдается:
openssl: /opt/cprocsp/cp-openssl-1.1.0/lib/amd64/libssl.so.1.1: version `OPENSSL_1_1_1' not found (required by openssl)
openssl: /opt/cprocsp/cp-openssl-1.1.0/lib/amd64/libcrypto.so.1.1: version `OPENSSL_1_1_1' not found (required by openssl)

Разные версии openssl.

Если пользуетесь нашими библиотеками openssl, по хорошему и саму утилиту openssl надо оттуда же использовать, а не системную.

Но в требованиях самой engine (gostengy) нет строгой привязки к нашему openssl, просто посмотрите как подключается engine в конфигурации openssl и сможете самостоятельно подключать gostengy к любому openssl старше 1.1.0, например системному.

Знания в базе знаний, поддержка в техподдержке
Offline alex_nur  
#333 Оставлено : 7 декабря 2020 г. 14:46:13(UTC)
alex_nur

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

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

Сказал(а) «Спасибо»: 2 раз
Я установил openssl от Крипто Про другой версии (не сертифицированной). А конкретно: после сборки nginx (работы скрипта install-nginx.sh) скачиваются свежии версии cprocsp-cpopenssl.
Установил их на машине-клиенте:
# dpkg -i cprocsp-cpopenssl-110-64_5.0.11803-6_amd64.deb cprocsp-cpopenssl-110-base_5.0.11803-6_all.deb cprocsp-cpopenssl-110-gost-64_5.0.11803-6_amd64.deb
На этот раз сообщения "WARNING! Higher openssl version detected, cp-openssl will not work properly. Use LD_LIBRARY_PATH to fix it. " не было.
И вывод на клиенте совпадает с выводом машины-сервера nginx:
OpenSSL> engine
(dynamic) Dynamic engine loading support
(gostengy) CryptoPro GostEngy ($Revision: 211453 $)
OpenSSL> version
OpenSSL 1.1.1d 10 Sep 2019 (Library: OpenSSL 1.1.1g 21 Apr 2020)

Причем запускается openssl без вопросов.
Offline Ефремов Степан  
#334 Оставлено : 7 декабря 2020 г. 17:12:28(UTC)
Ефремов Степан

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

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

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 17 раз в 16 постах
Автор: alex_nur Перейти к цитате
Я установил openssl от Крипто Про другой версии (не сертифицированной). А конкретно: после сборки nginx (работы скрипта install-nginx.sh) скачиваются свежии версии cprocsp-cpopenssl.
Установил их на машине-клиенте:
# dpkg -i cprocsp-cpopenssl-110-64_5.0.11803-6_amd64.deb cprocsp-cpopenssl-110-base_5.0.11803-6_all.deb cprocsp-cpopenssl-110-gost-64_5.0.11803-6_amd64.deb
На этот раз сообщения "WARNING! Higher openssl version detected, cp-openssl will not work properly. Use LD_LIBRARY_PATH to fix it. " не было.
И вывод на клиенте совпадает с выводом машины-сервера nginx:
OpenSSL> engine
(dynamic) Dynamic engine loading support
(gostengy) CryptoPro GostEngy ($Revision: 211453 $)
OpenSSL> version
OpenSSL 1.1.1d 10 Sep 2019 (Library: OpenSSL 1.1.1g 21 Apr 2020)

Причем запускается openssl без вопросов.


Нюансы с openssl описаны здесь:
1) https://www.cryptopro.ru...&m=115247#post115247
2) https://www.cryptopro.ru...&m=110120#post110120

Правильно ли я понимаю, что сейчас проблем нет?
Техническая поддержка здесь.
База знаний здесь.
Offline alex_nur  
#335 Оставлено : 8 декабря 2020 г. 13:28:40(UTC)
alex_nur

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

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

Сказал(а) «Спасибо»: 2 раз
Автор: Ефремов Степан Перейти к цитате

Нюансы с openssl описаны здесь:
1) https://www.cryptopro.ru...&m=115247#post115247
2) https://www.cryptopro.ru...&m=110120#post110120

Правильно ли я понимаю, что сейчас проблем нет?


Проблема появилась такого рода: мое приложение (net core) на машине с AstraLinux (с установленным КриптоПро CSP5 + openssl от Крипто Про) устанавливает HTTPS соединение с другой машиной AstraLinux (с установленным КриптоПро CSP5 + openssl от Крипто Про) c nginx по ГОСТ. При этом происходит аутентификация сервера. Проверка не проходит. Получаю исключение:
The SSL connection could not be established, see inner exception. The remote certificate is invalid according to the validation procedure.

В качестве эксперимента временно убрал на nginx использование ГОСТ, разрешив RSA (до установки КриптоПро через RSA связь была с Linux-машины на Linux машину). Ошибка та же самая при валидации сертификата.

Если же в качестве клиента выступает машина Windows с установленным КриптоПро CSP, то с проверкой сертификата нет проблем как с RSA так и через ГОСТ.

Корневые сертификаты добавлены в /usr/local/share/ca-certificates, запущен update-ca-certificates, который создал символьные ссылки на эти сертификаты в /etc/ssl/certs. Эти сертификаты доступны для чтения всем пользователям.

В обязательном порядке эти корневые сертификаты были добавлены в хранилище mroot в Крипто Про на машине с nginx и дополнительно в mroot для машине клиента.
Не помогло.

Выяснилось, что следующая команда также не может проверить доверие к сертификату сервера (на обоих машинах с установленным КриптоПро + openssl от Крипто Про):

# openssl s_client -connect srvuapp01.mydomain:443
Verify return code: 21 (unable to verify the first certificate)

Если же запустить эту проверку с других Linux-машин, на которых корневые сертификаты добавлены аналогичным образом (кроме как в mroot, т.к. КриптоПро на них не установлен), то все хорошо: Verify return code: 0 (ok)

Получается, что openssl (как и мое приложениие, судя по всему, использующее обращение к нему) на машинах с КриптоПро + openssl щт Крипто Про не смотрит штатное место хранения корневых сертификатов.
Команда с явным указанием каталога с сертификатами, завершается успехом:
# openssl s_client -CApath=/etc/ssl/certs -connect srvuapp01.mydomain:443
Verify return code: 0 (ok)

Где-нибудь можно указать путь к сертификатам для всей системы, в случае установки openssl от Крипто Про (т.е. вернуть поведение по умолчанию)?
Пробовал закомментировать строки в /etc/ld.so.conf :
#/opt/cprocsp/cp-openssl-1.1.0/lib/amd64
#/opt/cprocsp/lib/amd64
include /etc/ld.so.conf.d/*.conf

openssl теперь может проверить сертификат удаленного сервера без ключа -CApath. Но тогда перестает вообще запускаться мое приложение (т.к. первым делом там идет в параллельном потоке установка соединения с nginx) при попытке установки с nginx используя шифрование ГОСТ.
Если раскомментировать строки в /etc/ld.so.conf, то приложение запускается, но невозможно проверить сертификат сервера.

PS: Вот более детально при проверке сертификата сервера (из отладчика net core - приложения). Объект X509Chain имеет ChainStatus.X509ChainStatus.StatusInformation = "unable to get local issuer certificate".

Решено.

Я закомментировал строки в /etc/ld.so.conf, приведя файл к виду:
#/opt/cprocsp/cp-openssl-1.1.0/lib/amd64
#/opt/cprocsp/lib/amd64
include /etc/ld.so.conf.d/*.conf

Запустил
# openssl version -d
Вывод: OPENSSLDIR: "/var/opt/cprocsp/cp-openssl-1.1.0"

Раскоментировал ранее закомментированные строки в /etc/ld.so.conf
Запустил
# openssl version -d
Вывод: OPENSSLDIR: "/usr/lib/ssl"

В /var/opt/cprocsp/cp-openssl-1.1.0 существовали каталоги certs и private. Внутри было пусто. Отсюда и проблемы.
Я удалил пустые каталоги /var/opt/cprocsp/cp-openssl-1.1.0/certs и /var/opt/cprocsp/cp-openssl-1.1.0/private

Создал символьные ссылки вместо них с настоящего хранилища сертификатов:
ln -s /etc/ssl/certs /var/opt/cprocsp/cp-openssl-1.1.0
ln -s /etc/ssl/private /var/opt/cprocsp/cp-openssl-1.1.0

В итоге теперь и для openssl не нужно указывать -CApath, и мое приложение может проверять сертификат сервера. В итоге, все работает через ГОСТ. Ранее тоже работало, но проводить аутентификацию сервера - обязательное требование.
На решение натолкнуло чтение https://docs.microsoft.c...mpatibility/cryptography
Оттуда я узнал о ключе -d (openssl version -d)

Отредактировано пользователем 8 декабря 2020 г. 15:15:21(UTC)  | Причина: Решение

Offline Ефремов Степан  
#336 Оставлено : 8 декабря 2020 г. 15:25:29(UTC)
Ефремов Степан

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

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

Сказал(а) «Спасибо»: 1 раз
Поблагодарили: 17 раз в 16 постах
Отлично.

На всякий случай еще раз отмечу про engine: его можно подключать к системному openssl.
Нужно:
1) библиотека gostengy.so (из пакета cprocsp-cpopenssl-110-gost-64);
2) прописать ее в конфиге системного openssl.

В этом случае не придется устанавливать пакеты cpopenssl. Проблем с путями сертификатов, предположительно, так же не будет.
Техническая поддержка здесь.
База знаний здесь.
thanks 1 пользователь поблагодарил Ефремов Степан за этот пост.
alex_nur оставлено 09.12.2020(UTC)
Offline alex_nur  
#337 Оставлено : 9 декабря 2020 г. 12:17:29(UTC)
alex_nur

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

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

Сказал(а) «Спасибо»: 2 раз
Автор: Ефремов Степан Перейти к цитате
Отлично.

На всякий случай еще раз отмечу про engine: его можно подключать к системному openssl.
Нужно:
1) библиотека gostengy.so (из пакета cprocsp-cpopenssl-110-gost-64);
2) прописать ее в конфиге системного openssl.

В этом случае не придется устанавливать пакеты cpopenssl. Проблем с путями сертификатов, предположительно, так же не будет.


Подтверждаю. Так тоже работает. Проблем с путями нет.
Offline a1eksrulez  
#338 Оставлено : 1 февраля 2021 г. 13:53:58(UTC)
a1eksrulez

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

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

Добрый день, а подскажите пожалуйста, что означает эта ошибка в логе nginx в error 2021/02/01 10:13:57 [crit] 18900#18900: *9239 SSL_do_handshake() failed (SSL: error:1411C044:SSL routines:tls1_PRF:internal error) while SSL handshaking, client: 10.12.105.131, server: 0.0.0.0:443
Offline pd  
#339 Оставлено : 1 февраля 2021 г. 15:03:43(UTC)
pd

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

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

Сказал(а) «Спасибо»: 27 раз
Поблагодарили: 178 раз в 154 постах
Автор: a1eksrulez Перейти к цитате
Добрый день, а подскажите пожалуйста, что означает эта ошибка в логе nginx в error 2021/02/01 10:13:57 [crit] 18900#18900: *9239 SSL_do_handshake() failed (SSL: error:1411C044:SSL routines:tls1_PRF:internal error) while SSL handshaking, client: 10.12.105.131, server: 0.0.0.0:443

Сложно сказать, не встречали.

Как воспроизвести?
Знания в базе знаний, поддержка в техподдержке
Offline a1eksrulez  
#340 Оставлено : 2 февраля 2021 г. 13:26:26(UTC)
a1eksrulez

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

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

Автор: pd Перейти к цитате
Автор: a1eksrulez Перейти к цитате
Добрый день, а подскажите пожалуйста, что означает эта ошибка в логе nginx в error 2021/02/01 10:13:57 [crit] 18900#18900: *9239 SSL_do_handshake() failed (SSL: error:1411C044:SSL routines:tls1_PRF:internal error) while SSL handshaking, client: 10.12.105.131, server: 0.0.0.0:443

Сложно сказать, не встречали.

Как воспроизвести?


2021/02/02 10:15:17 [crit] 8298#8298: *703 SSL_do_handshake() failed (SSL: error:0609B099:digital envelope routines:EVP_PKEY_derive_set_peer:different parameters error:8001102A:lib(128):gng_pkey_decrypt_3410:GNG_ERR_INCOMPATIBLE error:1419D093:SSL routines:tls_process_cke_gost:decryption failed) while SSL handshaking, client: 10.12.105.131, server: 0.0.0.0:443

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