TLS в 2025: практичная настройка Nginx и Apache (TLS 1.3, шифры, OCSP, HSTS)

В 2025 «просто включить HTTPS» уже не равно «сделать безопасно и быстро». TLS 1.3 стал нормой, слабые протоколы и алгоритмы уходят, но ошибки в конфигурации по‑прежнему приводят к сюрпризам: от падения совместимости и отключения HTTP/2 до «фальшивого» OCSP stapling, который есть в конфиге, но не работает.

Ниже — практичный чек‑лист и рабочие пресеты для Nginx и Apache (mod_ssl), без магии и без привязки к онлайн‑сканерам. Примеры рассчитаны на современный OpenSSL (1.1.1+; оптимально — 3.x). Если у вас старый OpenSSL в системе или в сборке веб‑сервера, часть опций может быть недоступна.

Что считается «хорошим TLS» в 2025

Цели конфигурации обычно три:

• Безопасность: выключить устаревшие протоколы, не допускать слабые алгоритмы, корректно отдавать цепочку сертификатов.
• Производительность: приоритет TLS 1.3, возобновление сессий без сюрпризов, минимум лишних обращений к OCSP.
• Предсказуемость: настройки, которые переживают обновления и одинаково работают в разных окружениях.

Минимальный базис для большинства сайтов:

• TLS 1.2 и TLS 1.3 включены, всё старее — выключено.
• Для TLS 1.2 задан набор шифров через ssl_ciphers/SSLCipherSuite.
• Понимание, что ssl_prefer_server_ciphers/SSLHonorCipherOrder по сути влияет на TLS 1.2 (в TLS 1.3 выбор шифра устроен иначе).
• OCSP stapling включён и проверен реальным рукопожатием.
• HSTS включается осознанно, с планом «как откатываться».
• Проверки через openssl — до и после изменений.

Онлайн‑оценки «A+» полезны как индикатор, но не как цель. В проде обычно важнее стабильная совместимость и контроль изменений, чем погоня за предельными настройками.

Проверяем базу: версия OpenSSL и поддержка TLS 1.3

Перед тем как править конфиги, важно понять две вещи: какой OpenSSL доступен на сервере и с чем реально собран ваш веб‑сервер.

Проверка OpenSSL

openssl version -a

Проверка сборки Nginx

Смотрите, какую криптобиблиотеку он использует, и какие опции сборки включены:

nginx -V 2>&1 | tr ' ' '\n' | grep -E 'OpenSSL|TLS|--with-openssl'

Проверка Apache и модулей

apachectl -V

apachectl -M 2>&1 | grep ssl

Если у вас нет сертификата или срок подходит к концу, проще заранее выпустить или перевыпустить его и не смешивать «TLS‑тюнинг» с «пожаром по сертификату». Для коммерческих проектов часто удобнее управляемые SSL-сертификаты с понятным сроком и поддержкой.

Nginx: рекомендованный TLS‑пресет 2025

Это «сильный по умолчанию» пресет для типового сайта или приложения. Практичный подход — вынести его в отдельный include‑файл (например, tls.conf) и подключать в нужные server‑блоки.

Пример конфигурации для Nginx

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/example/fullchain.pem;
    ssl_certificate_key /etc/ssl/example/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;

    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
    ssl_prefer_server_ciphers on;

    ssl_session_cache shared:SSL:50m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

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

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Пояснения по ключевым директивам

ssl_protocols: в 2025 обычно достаточно оставить TLS 1.2 и 1.3. TLS 1.2 всё ещё нужен для части корпоративных клиентов и библиотек.

ssl_ciphers: это про TLS 1.2. Ошибка — пытаться «крутить TLS 1.3» через этот список. TLS 1.3 управляется иначе и в Nginx чаще всего сводится к факту наличия актуального OpenSSL и включённого TLS 1.3.

ssl_prefer_server_ciphers: заставляет использовать порядок шифров сервера для TLS 1.2. На TLS 1.3 влияет не так, как многие ожидают.

ssl_session_tickets off: безопасный выбор «без управления ключами тикетов». Если тикеты нужны для производительности на большой нагрузке, придётся отдельно продумать ротацию ключей и сценарии при нескольких инстансах.

ssl_stapling и ssl_stapling_verify: включают OCSP stapling и проверку ответа. Важная практическая деталь — resolver. Без резолвера stapling часто «не работает», особенно в контейнерах или минимальных системах.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Apache: рекомендованный TLS‑пресет 2025 (mod_ssl)

В Apache логика та же, но директивы другие. Ниже — базовый вариант для VirtualHost на 443. Убедитесь, что включены модули ssl, headers и (если используете проксирование) соответствующие proxy‑модули.

Пример конфигурации для Apache

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com

    SSLEngine on

    SSLCertificateFile /etc/ssl/example/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/example/privkey.pem

    SSLProtocol -all +TLSv1.2 +TLSv1.3

    SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
    SSLHonorCipherOrder on

    SSLUseStapling on
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off

    Header always set Strict-Transport-Security "max-age=15552000"

    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto "https"

    ProxyPass / http://127.0.0.1:8080/
    ProxyPassReverse / http://127.0.0.1:8080/
</VirtualHost>

На что обратить внимание в Apache

SSLHonorCipherOrder — аналог ssl_prefer_server_ciphers: принудительный порядок шифров сервера (по сути для TLS 1.2).

HSTS добавляется через mod_headers директивой Header. Проверьте, что модуль загружен:

apachectl -M 2>&1 | grep headers

Если вы сейчас выбираете, что ставить под проект (Nginx или Apache), полезно держать под рукой сравнение подходов и типовых кейсов: Nginx vs Apache в 2025: что выбрать под сайт и API.

OCSP stapling: типовые проблемы и диагностика

OCSP stapling уменьшает задержки и снижает зависимость от внешнего OCSP в момент соединения: сервер прикрепляет свежий OCSP‑ответ к TLS‑рукопожатию.

Частые причины, почему stapling не работает

• В Nginx не задан DNS‑резолвер (или он недоступен из окружения).
• Сертификат установлен без корректной цепочки (нужен fullchain).
• Фаервол или политики запрещают исходящие подключения к OCSP‑респондеру.
• Проблемы времени на сервере (NTP) и «слишком строгая» валидация: ответ выглядит невалидным.

Проверка stapling через openssl

openssl s_client -connect example.com:443 -servername example.com -tls1_3 -status

В выводе ищите блок OCSP response:. Если блока нет — stapling не отдаётся. Если есть — проверьте Cert Status и срок действия ответа.

HSTS в 2025: включаем аккуратно, чтобы не «запереть» домен

HSTS сообщает браузеру: «к этому домену — только по HTTPS». Это защищает от downgrade‑атак и случайных заходов по HTTP, но делает откат болезненным: браузер будет принудительно требовать HTTPS до истечения max-age.

Практичная стратегия включения HSTS

1. Начните с небольшого max-age (1–7 дней) и убедитесь, что HTTPS стабилен.
2. Постепенно увеличьте до 90–180 дней.
3. includeSubDomains и особенно preload включайте только после аудита поддоменов и внешних интеграций.

Если у домена есть сервисные поддомены, старые интеграции или подрядчики, HSTS с includeSubDomains без подготовки может превратиться в реальную аварию.

Пример HSTS (осторожный вариант)

Для Nginx:

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

Для Apache:

Header always set Strict-Transport-Security "max-age=604800"

Если вы параллельно усиливаете безопасность на уровне HTTP‑заголовков (не только HSTS), соберите всё в единый набор и применяйте последовательно: защитные HTTP‑заголовки для Nginx и Apache.

Шифры и параметры: как думать про ssl_ciphers и порядок шифров

Две типовые ошибки в проде:

• Пытаться «настроить TLS 1.3 через ssl_ciphers» (это настройка для TLS 1.2).
• Сделать набор для TLS 1.2 слишком узким и неожиданно поломать клиентов (особенно корпоративные агенты и старые Java‑стэки).

Если вы обслуживаете только современные браузеры и API‑клиентов, набор шифров из пресетов выше обычно достаточен. Если у вас B2B‑интеграции, старые устройства или embedded‑клиенты — держите TLS 1.2 включённым и проверяйте реальными клиентами, а не только сканерами.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Практические проверки: что реально отдают Nginx/Apache

Проверки через openssl удобны тем, что их можно гонять с «чистой» машины и автоматизировать в CI/CD.

Проверка TLS 1.3

openssl s_client -connect example.com:443 -servername example.com -tls1_3

Проверка TLS 1.2 и выбранного шифра

openssl s_client -connect example.com:443 -servername example.com -tls1_2

Смотрите строку Cipher. Если соединение не устанавливается — вы либо отключили TLS 1.2, либо слишком зажали ssl_ciphers/SSLCipherSuite.

Проверка цепочки сертификатов

openssl s_client -connect example.com:443 -servername example.com -showcerts

Если видите verify error, чаще всего сервер отдаёт неполную цепочку (нужен fullchain) или подмешан лишний или не тот промежуточный сертификат.

Частые ошибки в проде и как их избежать

«Включили TLS 1.3, а HTTP/2 не работает»

HTTP/2 завязан на ALPN. Проверьте, что Nginx слушает 443 с http2, а клиент реально договаривается о протоколе. В выводе openssl s_client (в зависимости от версии) можно увидеть, какой ALPN выбрался.

«OCSP stapling включили, но ответа нет»

Чаще всего виноваты резолвер или исходящий доступ. Начните с DNS и выхода в сеть от имени сервера, затем перепроверьте, что установлен fullchain.

«HSTS включили — и теперь нельзя быстро откатиться»

Это ожидаемое поведение. Поэтому вводите HSTS поэтапно и держите план: как вы будете обслуживать домен при форс‑мажоре с сертификатом или ключом.

«Настроили только RSA, хотя можно быстрее»

ECDSA‑сертификаты часто уменьшают размер подписей и нагрузку при рукопожатиях. В проде нередко делают dual‑cert (ECDSA + RSA) ради совместимости, но это следующий шаг: сначала стабилизируйте базовый пресет, цепочку и stapling.

Мини‑чеклист перед выкладкой изменений

• Есть тестовый server/VirtualHost на отдельном имени или порту.
• Проверено: TLS 1.3 подключается, TLS 1.2 подключается (если нужен), старые протоколы не принимаются.
• Проверено: корректная цепочка (fullchain), нет ошибок verify.
• Проверено: OCSP stapling отдаётся (-status).
• HSTS включён с разумным max-age и вы понимаете последствия.
• После перезагрузки или reload конфиг валиден.

Команды безопасного применения конфигурации

Nginx

nginx -t

systemctl reload nginx

Apache

apachectl configtest

systemctl reload apache2

Если важно «не уронить» соединения, используйте reload, а не restart: это снижает риск обрыва активных запросов.

Итог

Практичная настройка TLS для Nginx и Apache в 2025 сводится к понятному набору: TLS 1.3 + TLS 1.2, аккуратный ssl_ciphers для TLS 1.2, корректная цепочка сертификата, реально работающий OCSP stapling и осознанный HSTS. Дальше уже можно тонко оптимизировать под вашу нагрузку и клиентов: dual ECDSA/RSA, управляемые session tickets и особенности отдельных библиотек.

Сохраните пресеты как базу, и следующий TLS‑аудит будет занимать минуты, а не часы.