HTTPS без боли: выбор и установка SSL, автообновление, HSTS и редиректы

HTTPS уже давно стал нормой, а не опцией. Но даже в 2025‑м встречаются сайты с просроченными сертификатами, неочевидными 302‑редиректами и включённым HSTS на корневом домене без тестирования. В этой статье собрал практический чек‑лист: от выбора сертификата и установки с Certbot до автопродления, HSTS и аккуратной схемы редиректов.

Зачем HTTPS сегодня: безопасность, SEO и производительность

HTTPS защищает трафик, снижает риск подмены контента провайдерами и Wi‑Fi точками, открывает доступ к HTTP/2 и HTTP/3 (QUIC), улучшает позиции в поиске и повышает доверие пользователей. По факту, отсутствие TLS сегодня — это функциональный дефект: браузеры метят такие сайты как «Небезопасно», а часть современных API просто не работает без защищённого контекста.

SSL vs TLS и версии протокола

Технически мы говорим о TLS (SSL устарел как термин). На практике используйте TLS 1.2 и 1.3, выключайте 1.0/1.1. Для современного трафика приоритетен TLS 1.3 с ALPN для HTTP/2/3. Поддержка старых клиентов ради «совместимости» часто не оправдана с точки зрения риска.

Выбор сертификата: DV, OV, EV, wildcard и SAN

Типы валидации:

• DV (Domain Validation) — проверка владения доменом. Дешево/бесплатно, быстро. Почти всегда достаточно.
• OV/EV — проверка организации, но в браузере «зелёной строки» уже нет. Имеет смысл для корпоративного комплаенса.

По охвату имен:

• Обычный (single-name) — для одного FQDN: example.com или www.example.com.
• SAN (multi-domain) — несколько доменов/поддоменов в одном сертификате.
• Wildcard — *.example.com для всех поддоменов первого уровня (не покрывает сам example.com).

Wildcard удобен при множестве поддоменов, но требует DNS‑валидации (ACME DNS‑01). Для отдельных сервисов зачастую проще SAN‑сертификат.

Если нужен платный OV/EV/SAN, оформляйте и продлевайте через SSL-сертификаты — так проще закрыть вопросы комплаенса и получить поддержку.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Подготовка окружения: DNS, SNI и порты

Перед выпуском сертификата проверьте:

• DNS A/AAAA записей указывают на актуальный сервер.
• Порт 80 (HTTP) открыт для ACME HTTP‑01 (если не используете DNS‑01). Порт 443 (HTTPS) будет нужен после установки.
• Если несколько сайтов на одном IP, убедитесь, что сервер поддерживает SNI (все современные делают).

Если домен только планируется — оформите его через регистрацию доменов. А по проверке записей SPF/DKIM/DMARC и базовым A/AAAA см. практикум: DNS‑записи и аутентификация почты.

Установка через Certbot: быстрый старт

Certbot поддерживает плагины для Nginx/Apache и standalone‑режим. Ниже краткий путь для Ubuntu/Debian (репозитории snapd актуальны и содержат свежие версии):

# Установка
sudo snap install core; sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

# Вариант для Nginx (автоконфиг):
sudo certbot --nginx -d example.com -d www.example.com

# Вариант для Apache:
sudo certbot --apache -d example.com -d www.example.com

# Standalone (если веб‑сервер остановлен или порт 80 свободен):
sudo systemctl stop nginx || true
sudo certbot certonly --standalone -d example.com
sudo systemctl start nginx

Для wildcard используйте DNS‑валидацию:

sudo certbot -d *.example.com -d example.com --manual --preferred-challenges dns --certonly
# Certbot предложит создать TXT в _acme-challenge.example.com

На виртуальном хостинге авто‑SSL (Let’s Encrypt) часто включается в один клик в панели. Нужен полный контроль и root‑доступ? Разворачивайте на VDS и используйте Certbot/ACME‑клиенты без ограничений.

Где лежат файлы сертификата

По умолчанию Certbot хранит ключи и сертификаты в /etc/letsencrypt/. Основные пути:

• /etc/letsencrypt/live/DOMAIN/fullchain.pem — сертификат + цепочка.
• /etc/letsencrypt/live/DOMAIN/privkey.pem — приватный ключ.

Дайте доступ к ключам только пользователю/группе, от имени которых работает веб‑сервер. Не копируйте ключи в публичные директории.

Nginx: минимальный рабочий конфиг с TLS 1.3, HTTP/2 и OCSP Stapling

Базовая связка выглядит так:

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

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name 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_prefer_server_ciphers off;

    # OCSP Stapling
    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=31536000; includeSubDomains" always;
    add_header X-Content-Type-Options nosniff always;
    add_header Referrer-Policy no-referrer-when-downgrade always;

    root /var/www/example;
    index index.html index.php;

    location / {
        try_files $uri $uri/ =404;
    }
}

Если хотите принудительно перенаправлять www → apex (или наоборот), делайте это одной цепочкой: сначала HTTP→HTTPS, затем www→apex в HTTPS‑виртуалхосте. Так вы избежите лишних переходов.

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

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Apache: аналогичная схема

<VirtualHost *:80>
  ServerName example.com
  ServerAlias www.example.com
  Redirect 301 / https://example.com/
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
  ServerName example.com
  DocumentRoot /var/www/example

  SSLEngine on
  SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
  SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "no-referrer-when-downgrade"

  <Directory /var/www/example>
     Require all granted
  </Directory>
</VirtualHost>
</IfModule>

HSTS без сюрпризов

HSTS (HTTP Strict Transport Security) инструктирует браузеры всегда использовать HTTPS. Включайте его, когда:

• HTTPS корректно работает для домена и всех поддоменов, если используете includeSubDomains.
• Редиректы настроены, mixed content устранён.

Рекомендованная начальная настройка: max-age=86400 на несколько дней, затем увеличивайте до 6–12 месяцев. Директива preload отправляет домен в список HSTS браузеров — включайте только после стабильной работы и подтверждения, что все поддомены готовы.

Ошибка с HSTS может «запереть» пользователей на HTTPS даже если сертификат сломается. Тестируйте поэтапно и храните доступ к домену для экстренного восстановления.

Редиректы: 301, каноникал и порядок

Базовые принципы:

• Для постоянного перехода используйте 301.
• Исключите редирект‑петли и двойные прыжки (например, HTTP www → HTTPS www → HTTPS apex). Делайте сразу HTTP → HTTPS apex.
• Согласуйте редиректы с rel="canonical" и настройками веб‑приложения (CMS, фреймворки), чтобы не было конфликтов.

Если меняете домен или переносите проект, посмотрите подробный гайд: миграция домена, 301, HSTS и SSL.

Проверяйте цепочку через curl -I:

curl -I http://example.com
curl -I http://www.example.com
curl -I https://www.example.com

Автоматическое продление: Certbot timers и хук перезагрузки

Certbot по умолчанию ставит systemd‑таймер, который проверяет сертификаты 2 раза в день и продлевает, когда до истечения остаётся <30 дней. Посмотрите статус:

systemctl list-timers | grep certbot
journalctl -u snap.certbot.renew.service -n 100 --no-pager

Если нужен перезапуск Nginx/Apache после обновления, добавьте хук:

sudo sh -c 'printf "#!/bin/sh\nsystemctl reload nginx\n" > /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh'
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Проверьте сухой прогон:

sudo certbot renew --dry-run

Коммерческий сертификат: ручная установка

Если используете платный сертификат (OV/EV/SAN от другого CA):

1. Сгенерируйте ключ и CSR: openssl req -new -newkey rsa:2048 -nodes -keyout example.key -out example.csr -subj "/CN=example.com".
2. Передайте CSR в CA, получите cert.crt и цепочку chain.crt.
3. Соберите fullchain.pem как cat cert.crt chain.crt > fullchain.pem, используйте вместе с example.key в конфиге Nginx/Apache.

Не забывайте про календари и мониторинг срока истечения — автопродление тут не сработает без интеграции с API CA. При необходимости оформляйте и продляйте через SSL-сертификаты.

Mixed content и CSP

После включения HTTPS проверьте, что ресурсы (изображения, шрифты, JS, CSS) грузятся по HTTPS. Иначе браузер заблокирует их частично или полностью. Полезно добавить в CSP директиву upgrade-insecure-requests, которая автоматически переводит http:// ресурсы на HTTPS, если они доступны:

add_header Content-Security-Policy "upgrade-insecure-requests" always; # Nginx
# Apache: Header always set Content-Security-Policy "upgrade-insecure-requests"

Эта директива не спасает, если внешний источник не поддерживает HTTPS — такие ссылки нужно заменить вручную.

Производительность: HTTP/2/3, TLS 1.3, сжатие и кеш

Включите HTTP/2 в конфиге 443‑виртуалхоста, для Nginx — флаг http2. HTTP/3 требует отдельной конфигурации (QUIC/UDP, поддержка в вашем сервере). TLS 1.3 снижает накладные расходы рукопожатия. Помните про gzip/brotli, корректные заголовки кеширования и оптимизацию цепочки сертификата (короткая цепочка ускоряет установку соединения).

Проверка и отладка

Быстрые проверки:

• openssl s_client -connect example.com:443 -servername example.com -tls1_2 — детали цепочки и OCSP.
• curl -I https://example.com — коды ответов, заголовки (HSTS, CSP).
• Проверьте, что при обращении к http:// вы всегда получаете 301 на канонический HTTPS‑адрес.

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

• Порт 80 закрыт при выпуске — ACME HTTP‑01 не сработает. Откройте 80 временно или используйте DNS‑01.
• Неполная цепочка сертификата — некоторые клиенты не доверяют. Убедитесь, что используете fullchain.pem, а не только cert.pem.
• Несоответствие домена и сертификата — проверьте server_name и SAN‑список.
• Ключ/сертификат с неверными правами — веб‑сервер не может их читать. Настройте владельца/группу и chmod 640.
• Часы на сервере отстают — проверка OCSP/TLS может падать. Синхронизируйте NTP.
• Двойные/циклические редиректы — проверьте приоритет правил на уровне приложения и веб‑сервера.

Мониторинг срока истечения

Минимум — напоминание в календаре. Лучше — автоматические проверки. Примеры:

• Скрипт: echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates.
• Пробный certbot renew --dry-run раз в неделю + алерты по логам systemd.
• Метрики в Prometheus/интеграция со своим мониторингом на уровне TCP/HTTP.

Пошаговый план внедрения без даунтайма

1. Подготовьте DNS и тестовый поддомен, выпустите DV‑сертификат.
2. Включите HTTPS параллельно с HTTP, проверьте приложение, статические ресурсы.
3. Настройте редиректы и каноникал, убедитесь в однозначности маршрута.
4. Добавьте HSTS с небольшим max-age, мониторьте логи и ошибки.
5. Увеличьте max-age, при необходимости добавьте includeSubDomains и только затем думайте о preload.
6. Настройте автопродление и перезагрузку сервиса, добавьте мониторинг истечения.

Итоги

Современный стек HTTPS — это TLS 1.2/1.3, корректные редиректы, HSTS после тестирования, автопродление сертификатов и мониторинг. Используйте Certbot для быстрой установки и обновления, следите за цепочкой и mixed content, и проверяйте реальное поведение редиректов — тогда HTTPS настраивается «без боли» и не отнимает время у команды.