# 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/uk/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/uk/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/uk/kb/nginx-ssl-tls-nastroika/