Что нужно Nginx для работы по HTTPS

Для приёма соединений по HTTPS серверному блоку нужны три вещи: сертификат, приватный ключ и директива ssl_protocols, которая ограничивает список разрешённых версий TLS. Сертификат подтверждает, что домен принадлежит владельцу сервера, ключ используется для расшифровки трафика, а версия протокола определяет, какие браузеры и боты смогут подключиться.

Бесплатный сертификат от Let's Encrypt через certbot закрывает большинство случаев и автоматически продлевается по cron. Как выпустить и подключить такой сертификат на практике, описано в статье про SSL в Nginx через certbot. Здесь разберём саму серверную конфигурацию: какие директивы обязательны и почему набор шифров важнее, чем кажется.

Базовый server block для HTTPS

Минимальная рабочая конфигурация с сертификатом уже на диске выглядит так.

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.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;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers off;

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

fullchain.pem обязательно должен включать промежуточный сертификат центра сертификации, иначе часть браузеров и все консольные клиенты вроде curl будут ругаться на неполную цепочку, хотя в обычном браузере страница откроется благодаря кэшу цепочек.

Редирект с HTTP на HTTPS без петель

После включения HTTPS старый порт 80 нужно превратить в редирект, а не оставлять его отдающим тот же контент.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Частая ошибка — редирект внутри того же блока, где уже включён listen 443 ssl: тогда при попытке зайти по HTTP браузер получает TLS-ошибку раньше, чем успевает сработать return. Общие правила для директив rewrite и return разобраны в статье про редиректы в Nginx.

Протоколы и наборы шифров: что выбрать в 2026 году

TLS 1.0 и TLS 1.1 официально устарели и отключены в современных браузерах — держать их включёнными не даёт выигрыша в совместимости, зато оставляет уязвимую поверхность.

Протокол	Статус	Рекомендация
TLS 1.0 / 1.1	устарел, уязвим	отключить
TLS 1.2	поддерживается везде	оставить для совместимости
TLS 1.3	текущий стандарт	использовать как основной

Для TLS 1.3 набор шифров задаётся отдельно через ssl_conf_command Ciphersuites, поскольку старая директива ssl_ciphers на него не влияет. На VDS ZevsHost.net с современным OpenSSL достаточно строки ssl_ciphers HIGH:!aNULL:!MD5; для TLS 1.2 — она отсекает нешифрованные и устаревшие алгоритмы, не трогая быстрые современные шифры.

Проверка настройки: что смотреть после деплоя

После правки конфига нужно убедиться, что сертификат отдаётся правильно и без ошибок цепочки.

nginx -t — синтаксическая проверка конфига перед перезапуском.
openssl s_client -connect example.com:443 -servername example.com — какой сертификат и протокол реально согласовались.
curl -vI https://example.com/ — код ответа и заголовки без сертификатных предупреждений.
Проверка срока действия сертификата: openssl x509 -enddate -noout -in fullchain.pem.

Итог: чек-лист SSL/TLS в Nginx

В ssl_protocols оставлены только TLSv1.2 и TLSv1.3.
ssl_certificate указывает на fullchain, а не только на сертификат домена.
Порт 80 отдаёт редирект 301 на https, а не дублирует контент.
Автопродление сертификата проверено через certbot renew --dry-run.
После деплоя выполнена проверка openssl s_client и curl -vI.

SSL/TLS в Nginx: сертификаты, протоколы и шифры