И еще проблема появилась.
Необходимо к хосту с 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)  | Причина: Решение

Я установил 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 без вопросов.

Проблема появилась такого рода: мое приложение (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)  | Причина: Решение

Подтверждаю. Так тоже работает. Проблем с путями нет.

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

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