Перейти к содержанию

Закрытый ключ Nginx на аппаратном PKCS#11-токене

Закрытый ключ TLS-сервера может храниться на HSM или криптографическом токене, а Nginx — использовать его через OpenSSL и соответствующий PKCS#11 Provider. Таким образом можно исключить размещение экспортируемого закрытого ключа на файловой системе сервера.

Компоненты

  1. Совместимый аппаратный ГОСТ-токен и модуль PKCS#11 производителя.
  2. PKCS#11 Provider для OpenSSL 3, поддерживающий операции устройства.
  3. Сертификат с открытым ключом на диске Nginx.
  4. Доступ службы к токену и управляемый способ PIN-аутентификации.
  5. Совместимый TLS-профиль.

Подробная настройка PKCS#11 и OpenSSL.

Путь к ключу в конфигурации Nginx

Nginx поддерживает формат store:scheme:id для ssl_certificate_key с провайдерскими URI. Например:

ssl_certificate /etc/nginx/gost/server-chain.pem;
ssl_certificate_key "store:pkcs11:token=NiceOS-Test;object=Server-Key;type=private";

Это пример синтаксиса, а не универсальный готовый URI. Идентификатор должен быть получен из PKCS#11-объектов конкретного токена. Нельзя вписывать PIN в URI или в общедоступные конфигурационные файлы.

Проверка

openssl list -providers
sudo nginx -t

После проверки доступности токена и успешной тестовой подписи выполните HTTPS-подключение и убедитесь, что сертификат соответствует аппаратному ключу. Если TLS-процесс не имеет доступа к токену или требуется интерактивный PIN на каждом handshake, заранее подготовьте эксплуатационную модель.

Отказоустойчивость

  • Потеря токена может остановить новые TLS-рукопожатия.
  • При смене ключа выпускается новый сертификат.
  • Планируйте резервирование HSM и регламент замены носителя.
  • Никогда не переводите ключ в экспортируемый режим только ради упрощения резервирования.

См. механизмы PKCS#11 и ротацию ключей.