Статус: Новичок
Группы: Участники
Зарегистрирован: 27.11.2020(UTC) Сообщений: 4 ![Российская Федерация Российская Федерация](/forum2/Content/images/flags/RU.png)
|
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)
| Причина: Не указана
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 31.08.2017(UTC) Сообщений: 49 ![Российская Федерация Российская Федерация](/forum2/Content/images/flags/RU.png) Сказал(а) «Спасибо»: 1 раз Поблагодарили: 17 раз в 16 постах
|
Перезапустил сборку на трависе - прошла.
Это означает: либо вы что-то упустили, либо проблема в новом CSP, в чем я пока сомневаюсь.
Смущает так же эта запись: "lsb-cprocsp-kc2:i386".
Попробуйте сделать заного по инструкции. Если будет аналогичная ошибка, то можно посмотреть в syslog, может там будут подробности. |
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 27.11.2020(UTC) Сообщений: 4 ![Российская Федерация Российская Федерация](/forum2/Content/images/flags/RU.png)
|
Все удалось настроить, только пришлось выпускать и подписывать сертификат ручками загружая запрос на уц непосредственно. Дальше проделывать все процедуры написанные пошагово.
Я допускаю что где-то что-то делал не так, но ошибка была после штатной отработки скрипта. Плюс запрос на новый сертификат с установленной и сконфигурированной системой которая работала месяц назад тоже вывалился с ошибкой про CURL, и там я точно ничего не переделывал (хотя могло и автоматом что-то обновиться).
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 31.08.2017(UTC) Сообщений: 49 ![Российская Федерация Российская Федерация](/forum2/Content/images/flags/RU.png) Сказал(а) «Спасибо»: 1 раз Поблагодарили: 17 раз в 16 постах
|
Автор: Justz ![Перейти к цитате Перейти к цитате](/forum2/Themes/soclean/icon_latest_reply.gif) Все удалось настроить, только пришлось выпускать и подписывать сертификат ручками загружая запрос на уц непосредственно. Дальше проделывать все процедуры написанные пошагово.
Я допускаю что где-то что-то делал не так, но ошибка была после штатной отработки скрипта. Плюс запрос на новый сертификат с установленной и сконфигурированной системой которая работала месяц назад тоже вывалился с ошибкой про CURL, и там я точно ничего не переделывал (хотя могло и автоматом что-то обновиться).
Проверил с версией CSP 11944-6 как у вас - работает. Может есть что-нибудь подозрительное в /var/log/syslog после получения ошибки про CURL при отправке запроса? Пока не воспроизводится. |
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 19.11.2020(UTC) Сообщений: 21
Сказал(а) «Спасибо»: 4 раз Поблагодарили: 1 раз в 1 постах
|
Добрый день. Получилось у меня запустить через ГОСТ.
Проблема в том, что все работает из под пользователя 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 и сделать символьную ссылку на каталог контейнера?
|
|
|
|
Статус: Сотрудник
Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC) Сообщений: 1,488 Откуда: КРИПТО-ПРО
Сказал(а) «Спасибо»: 33 раз Поблагодарили: 451 раз в 326 постах
|
Автор: alex_nur ![Перейти к цитате Перейти к цитате](/forum2/Themes/soclean/icon_latest_reply.gif) Добрый день. Получилось у меня запустить через ГОСТ.
Проблема в том, что все работает из под пользователя 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, такие ограничения. |
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 19.11.2020(UTC) Сообщений: 21
Сказал(а) «Спасибо»: 4 раз Поблагодарили: 1 раз в 1 постах
|
Был готовый 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. Возможно ли создать два одинаковых контейнера для разных пользователей?
|
|
|
|
Статус: Сотрудник
Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC) Сообщений: 1,488 Откуда: КРИПТО-ПРО
Сказал(а) «Спасибо»: 33 раз Поблагодарили: 451 раз в 326 постах
|
Автор: alex_nur ![Перейти к цитате Перейти к цитате](/forum2/Themes/soclean/icon_latest_reply.gif) Т.е. мне надо для www-data контейнер создать, т.к. я создал для root. Возможно ли создать два одинаковых контейнера для разных пользователей? Как вам удобнее, но nginx должен запускаться и работать от одного и того же пользователя (на котором ключи и сертификаты), если хотите использовать gostengy. Отредактировано пользователем 4 декабря 2020 г. 14:05:00(UTC)
| Причина: Не указана |
|
![thanks](/forum2/Themes/soclean/heart_small.png) 1 пользователь поблагодарил pd за этот пост.
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 19.11.2020(UTC) Сообщений: 21
Сказал(а) «Спасибо»: 4 раз Поблагодарили: 1 раз в 1 постах
|
Автор: pd ![Перейти к цитате Перейти к цитате](/forum2/Themes/soclean/icon_latest_reply.gif) Автор: alex_nur ![Перейти к цитате Перейти к цитате](/forum2/Themes/soclean/icon_latest_reply.gif) Т.е. мне надо для 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?
|
|
|
|
Статус: Сотрудник
Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC) Сообщений: 1,488 Откуда: КРИПТО-ПРО
Сказал(а) «Спасибо»: 33 раз Поблагодарили: 451 раз в 326 постах
|
Автор: alex_nur ![Перейти к цитате Перейти к цитате](/forum2/Themes/soclean/icon_latest_reply.gif) В итоге имеем безопасный ГОСТ, и уменьшение безопасности в другом.
Есть идеи как запустить процесс, запускающий сокет на 443 порту не из под root? Вам предложили терминировать TLS трафик отдельным nginx от рута и делать proxy_pass на остальные бэкенды. Мы не запрещаем экспериментальных конфигураций, но это уже упражнения для самостоятельного освоения. |
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close