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)  | Причина: Не указана

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

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

Добрый день. Получилось у меня запустить через ГОСТ.

Проблема в том, что все работает из под пользователя 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 и сделать символьную ссылку на каталог контейнера?

Был готовый 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. Возможно ли создать два одинаковых контейнера для разных пользователей?

Установил таким же образом сертификат и контейнер для пользователя 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?