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

Уведомление

Icon
Error

39 Страницы«<3233343536>»
Опции
К последнему сообщению К первому непрочитанному
Offline alex_nur  
#331 Оставлено : 7 декабря 2020 г. 12:47:30(UTC)
alex_nur

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

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

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 1 раз в 1 постах
И еще проблема появилась.
Необходимо к хосту с 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,441
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 31 раз
Поблагодарили: 411 раз в 306 постах
Автор: 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)
Сообщений: 21

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 1 раз в 1 постах
Я установил 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)
Сообщений: 21

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

Нюансы с 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)
Сообщений: 21

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

На всякий случай еще раз отмечу про 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,441
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 31 раз
Поблагодарили: 411 раз в 306 постах
Автор: 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 Лента
Пользователи, просматривающие эту тему
39 Страницы«<3233343536>»
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.