Що потрібно 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: сертифікати, протоколи і шифри