Безопасная TLS-конфигурация Nginx без опасных шаблонов

HTTPS работает, когда сервер предъявляет сертификат для нужного домена и доказывает владение соответствующим приватным ключом. Клиент проверяет имя, срок действия и цепочку доверия до известного центра сертификации. Одной зелёной проверки nginx -t для этого недостаточно: она не воспроизводит подключение браузера.

Настройка состоит из четырёх частей: получить сертификат штатным ACME-клиентом, закрыть доступ к приватному ключу, подключить оба файла в правильном виртуальном хосте и проверить соединение снаружи. Затем нужно убедиться, что автоматическое продление действительно выполняется.

Условия до настройки

Домен должен разрешаться на нужный сервер, входящий порт HTTPS — быть доступен, а часы системы — синхронизированы. Определите, где завершается TLS. Если сертификат обслуживает CDN или внешний балансировщик, конфигурация внутреннего Nginx будет другой.

Сохраните действующую конфигурацию и убедитесь, что есть второй SSH-сеанс или консоль хостера. Посмотрите сборку:

nginx -V
openssl version

Версии важны для поддерживаемых протоколов и директив, но обновлять production посреди настройки сертификата без отдельного плана не следует.

Подключите сертификат к нужному домену

В отдельном server-блоке укажите HTTPS-порт, точное имя домена, файл полной цепочки и приватный ключ. Пути ниже характерны для Certbot, но перед копированием их нужно сверить на своём сервере:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;

    root /var/www/example/current;
    index index.html;
}

Пути — пример. Файл сертификата должен содержать сертификат сайта, а затем необходимые промежуточные сертификаты. Приватный ключ читается master-процессом Nginx и не должен быть доступен посторонним пользователям. Не ослабляйте права только ради прохождения проверки; исправьте владельца и штатную интеграцию ACME-клиента.

Поддержка TLS 1.3 зависит от сборки Nginx и криптографической библиотеки. Если nginx -t сообщает об ошибке, сверяйтесь с документацией именно вашей поддерживаемой версии. Не возвращайте устаревший протокол ради неизвестного клиента без оценки риска.

Почему не стоит вставлять случайный набор шифров

Директивы шифров зависят от OpenSSL, политики ОС и требуемых клиентов. Старый «усиленный» шаблон способен отключить современные устройства, сохранить слабые алгоритмы или конфликтовать с обновлёнными defaults. Начните с поддерживаемой конфигурации дистрибутива или ACME-инструмента, зафиксируйте требования совместимости и проверяйте изменения отдельно.

Та же осторожность нужна параметрам сессий, OCSP и дополнительным модулям. Они полезны в определённых схемах, но не должны появляться без мониторинга и понимания отказов.

Проверьте конфигурацию и примените без разрыва

sudo nginx -t
sudo systemctl reload nginx
systemctl status nginx --no-pager
sudo journalctl -u nginx --since "5 minutes ago"

Reload сохраняет существующие соединения при корректной конфигурации. Если проверка не прошла, не перезапускайте службу: исправьте путь, права или синтаксис и повторите тест.

Проверьте SNI и цепочку

Проверьте соединение с другого узла, чтобы запрос прошёл настоящий сетевой путь. Первая команда покажет сертификаты и результат проверки цепочки, вторая — TLS-обмен и HTTP-заголовки:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
curl -Iv https://example.com/

Параметр -servername отправляет SNI, чтобы Nginx выбрал правильный виртуальный хост. Проверьте имя, срок, издателя, цепочку и итог проверки, затем реальный HTTP-ответ. Успешный TLS не гарантирует, что приложение возвращает правильную страницу.

Отдельно проверьте каждый HTTPS-алиас, включая www. Сертификат должен покрыть имя даже тогда, когда сервер только возвращает редирект.

Продление — часть конфигурации

Узнайте, какой ACME-клиент выдавал сертификат, где находится его timer/cron и какой hook выполняет reload. Не создавайте второй механизм поверх существующего. Посмотрите timers:

systemctl list-timers --all | grep -Ei 'cert|acme'

Команда тестового продления зависит от клиента. Запускайте только его документированный dry-run и после него проверяйте журнал. Настройте оповещение о приближении срока: автоматизация без наблюдения может молча сломаться после изменения DNS или firewall.

HSTS включают последним

Заголовок HSTS сообщает браузеру принудительно использовать HTTPS в течение max-age. Начните с короткого проверочного периода только после стабильной работы:

add_header Strict-Transport-Security "max-age=86400" always;

Не добавляйте includeSubDomains и preload, пока каждый поддомен не готов постоянно обслуживать HTTPS. Увеличение срока — отдельное осознанное решение. Отключение заголовка на сервере не отменит уже сохранённую браузером политику мгновенно.

Диагностика типовых ошибок

• nginx -t не читает ключ — проверьте путь, права и владельца, не делайте ключ общедоступным;
• браузер видит чужой сертификат — проверьте server_name, SNI и default server;
• цепочка неполная — используйте файл полной цепочки от ACME-клиента;
• после продления остаётся старый сертификат — проверьте фактический файл, hook reload и внешний TLS-терминатор;
• HTTP работает, HTTPS нет — проверьте listen, firewall и маршрут до сервера.

Если изменение сломало сайт, верните сохранённый конфиг и reload только после успешного nginx -t. Связанные шаги: домен, Nginx и HTTPS, редиректы и канонический адрес и атомарный deploy.

Запишите владельца продления, дату следующего автоматического запуска и канал оповещения. После обновления Nginx или OpenSSL повторите внешний TLS-тест: успешный пакетный upgrade ещё не подтверждает доступность каждого виртуального хоста.

Первоисточники

• Nginx: ngx_http_ssl_module — сертификаты, ключи, протоколы и TLS-директивы.
• OpenSSL: s_client — диагностическое подключение, SNI и вывод цепочки.