Кейс: Подключение сертификата безопасности ГОСТ к сайту с поддержкой параллельного использования стандартного RSA

Схема работы ГОСТ и RSA сертификатов одновременно

Для одного из сайтов клиент у нас затребовал использовать на сайте сразу 2 сертификата - стандартный RSA Wildcard и сертификат Минцифры и Центрального банка РФ соответствующий ГОСТ шифрованию. Сайт работает на основе BitrixVM, обслуживаемый классическим Nginx (порт 443) с проксированием на Nginx/Apache в бэкенде.

Требования:

• поддержать шифрование по ГОСТ (сертификаты Минцифры, ЦБ и т.д.);
• при этом сохранить поддержку обычных RSA‑сертификатов (клиенты без ГОСТ должны продолжать работать по стандартному TLS);
• минимально менять существующую архитектуру, чтобы не ломать текущий бэкенд и настройки.

Решение — внедрить cpnginx (Nginx с поддержкой CryptoPro/ГОСТ) как фронтовой сервер на 443‑м порту, а обычный Nginx перенести на другой порт (например, 4443) и использовать его как внутренний HTTPS‑бэкенд.

Целевая архитектура

После внедрения схема обмена будет выглядеть так:

1. Клиент (браузер/ПО) устанавливает HTTPS‑соединение с фронтовым сервером cpnginx на порту 443.
   * Если клиент умеет ГОСТ, используется ГОСТ‑сертификат.
   * Если клиент работает только с классическим TLS/RSA, используется RSA‑сертификат.
2. cpnginx принимает запрос, а дальше:
   * отдаёт статический контент (если он запрошен и настроен в конфиге), или
   * по HTTPS проксирует запрос на внутренний Nginx, работающий на порту 4443.
3. Внутренний Nginx уже ведёт себя как раньше:
   * либо сам отдаёт «статику»,
   * либо проксирует запросы на Apache/PHP‑FPM/приложение.

Таким образом, шифрование ГОСТ добавляется только на внешнем уровне, не нарушая существующую внутреннюю инфраструктуру.

Подготовка криптопровайдера и доверенных корневых сертификатов

Для корректной работы ГОСТ‑TLS необходимо:

• чтобы cpnginx доверял корневым сертификатам Минцифры. Он уже предустановлен, поэтому повторную установку игнорируем;
• чтобы он доверял сертификатам регулятора (например, ЦБ РФ) и другим нужным центрам сертификации.

На этом этапе:

• добавляем корневой сертификат ЦБ (и других необходимых УЦ) в пользовательское хранилище, от имени системного пользователя cpnginx;
• при этом используются штатные утилиты криптопровайдера (CryptoPro) для установки сертификатов в соответствующие хранилища.

В кейсе важно, что:

• разграничены хранилища для корневых и промежуточных сертификатов;
• все операции выполняются от имени пользователя cpnginx, чтобы сервис имел доступ к добавленным сертификатам без лишних прав.

Подготовка и установка ГОСТ‑сертификатов

Размещаем гостовские сертификаты в отдельном контейнере, к которому cpnginx имеет доступ.

Ключевые моменты:

• создаётся/используется каталог ключей, принадлежащий пользователю cpnginx с ограниченными правами доступа;
• в этот каталог копируются несколько ключевых файлов ГОСТ (каждый файл — отдельный сертификат/ключ для разных задач или доменов);
• выставляются строгие права доступа (чтение/запись только владельцу, запрет доступа остальным).

После физического размещения ключей:

• выполняется команда (через утилиты CryptoPro) для «подключения» этих сертификатов к программному хранилищу;
• провайдер автоматически подхватывает новые сертификаты и делает их доступными для использования в cpnginx.

В результате в личном хранилище сертификатов пользователя cpnginx появляется несколько ГОСТ‑сертификатов, которые далее можно указать в конфиге.

Подготовка и установка RSA‑сертификата

Чтобы cpnginx параллельно поддерживал стандартный TLS с RSA‑сертификатом, выполняется:

Объединение RSA‑ключа и цепочки сертификатов в один контейнер формата PFX.

1. Используется openssl или аналогичный инструмент.
2. В контейнер включаются:
   * приватный RSA‑ключ домена;
   * основной сертификат домена;
   * промежуточные и корневые сертификаты УЦ.

Установка этого PFX‑контейнера через утилиту CryptoPro в хранилище сертификатов пользователя cpnginx.

1. Указывается тип провайдера, соответствующий поддержке PFX и RSA.
2. После установки сертификат становится доступен cpnginx наравне с ГОСТ‑сертификатами.

Сохраняем серийные номера гостовского и RSA - они нам пригодятся дальше для конфига системы.

Настройка cpnginx как фронтового HTTPS‑сервера

В конфигурации cpnginx (как правило, отдельный файл в conf.d) описывается серверный блок для домена:

• listen 443 sspi; — включение специального режима, в котором TLS‑рукопожатие и криптография переданы CryptoPro (SSPI/ГОСТ‑TLS);
• server_name domain.ru; — домен магазина.

Далее в конфиге:

• указываются несколько директив с серийными номерами сертификатов:
  * одна директива — для ГОСТ‑сертификата;
  * другая — для RSA‑сертификата;
• указывается список поддерживаемых версий протокола (например, только TLS 1.2).

За счёт того, что cpnginx знает о наличии нескольких сертификатов, он сможет:

• при рукопожатии выбирать ГОСТ‑сертификат для клиентов, поддерживающих ГОСТ;
• использовать RSA‑сертификат для обычных браузеров без ГОСТ‑криптографии.

Для проксирования на внутренний Nginx:

• прописывается proxy_pass на https://127.0.0.1:4443;
• задаются стандартные заголовки (Host, X-Real-IP, X-Forwarded-For, X-Forwarded-Proto и т.п.), чтобы бэкенд корректно понимал исходный домен и IP клиента;
• выставляются таймауты и параметры keep-alive;
• при необходимости настраивается проверка сертификата/CRL при установлении внутреннего HTTPS‑соединения.

Отдельно настраивается страница ошибок (например, для 50x), которая будет отдаваться непосредственно cpnginx, если бэкенд недоступен.

Переключение ролей между Nginx и cpnginx

Чтобы внедрить новую схему без простоя:

1. Останавливается стандартный Nginx в роли фронта и одновременно включается cpnginx как системный сервис с автозапуском.
2. Конфигурация обычного Nginx меняется таким образом, чтобы он больше не слушал 443 порт, а перешёл на 4443 (или любой другой внутренний). На этом порту он уже не занимается внешним TLS, а принимает запросы от cpnginx по HTTPS.
3. Перезапускается обычный Nginx с новой конфигурацией.

После этого:

• все внешние клиенты приходят на cpnginx:443;
• cpnginx занимается только терминацией шифрованного соединения (ГОСТ или RSA);
• дальше запросы уходят на внутренний Nginx/Apache, где логика сайта не меняется.

Результат и практические эффекты

В итоге получен следующий результат:

• Доменные имена (например, domain.ru) стали доступны по HTTPS как с ГОСТ‑сертификатами, так и с классическими RSA, без необходимости разделять их по разным доменам или портам.
• Сохранилась существующая серверная архитектура: Nginx + Apache, все прежние конфиги, правила, переписывания URL и т.д. продолжают работать.
• Внешний периметр стал соответствовать требованиям по использованию отечественных криптографических алгоритмов, при этом не ограничивая «обычных» пользователей с классическими браузерами.
• Управление сертификатами сосредоточено в инфраструктуре CryptoPro: корневые, ГОСТ‑ключи, RSA‑PFX — всё в едином хранилище пользователя cpnginx, с единым набором утилит для администрирования.

Подписывайтесь на наш телеграм https://t.me/official_3rednet

#ГОСТ #ГОСТTLS #CryptoPro #cpnginx #Nginx #SSL #TLS #RSA #ИнформационнаяБезопасность #Криптография #РоссийскаяКриптография #DevOps #SysAdmin #WebSecurity #TLSНастройка #Инфраструктура #SSLСертификаты #LinuxAdmin #HTTPS #BitrixVM