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

Уведомление

Icon
Error

39 Страницы«<3132333435>»
Опции
К последнему сообщению К первому непрочитанному
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)
Сообщений: 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 и сделать символьную ссылку на каталог контейнера?



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

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

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

Сказал(а) «Спасибо»: 31 раз
Поблагодарили: 412 раз в 306 постах
Автор: 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)
Сообщений: 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. Возможно ли создать два одинаковых контейнера для разных пользователей?
Offline pd  
#328 Оставлено : 4 декабря 2020 г. 14:04:24(UTC)
pd

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

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

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

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 1 раз в 1 постах
Автор: 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,442
Откуда: КРИПТО-ПРО

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

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

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

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


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