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

> Настройка SSL/TLS в Nginx: путь к сертификату, выбор протоколов и наборов шифров, редирект на HTTPS и проверка результата.

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

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

Бесплатный сертификат от Let's Encrypt через certbot закрывает большинство случаев и автоматически продлевается по cron. Как выпустить и подключить такой сертификат на практике, описано в статье про [SSL в Nginx через certbot](https://www.zevshost.net/ru/kb/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](https://www.zevshost.net/ru/kb/nginx-rewrite-return-redirect/).

## Протоколы и наборы шифров: что выбрать в 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`.

---

Источник: https://www.zevshost.net/ru/kb/nginx-ssl-tls-nastroika/