HTTPS и жизненный цикл сертификата

В предыдущем уроке мы связали домен с адресом и виртуальным сайтом. Теперь добавим защищённое соединение. Для release-lab недостаточно иметь файл сертификата где-то на сервере: он должен покрывать нужное имя, использоваться правильным виртуальным сайтом и обновляться без ручного аврала. Разберём этот жизненный цикл до настройки конкретного Nginx.

Основное имя стенда — example.com, тестовое — staging.example.com. Сертификаты для учебных имён в этой статье не выпускались; читатель заменит их своими именами на отдельном стенде. На виртуальном хостинге часть работы выполняет провайдер, а на VPS ответственность за клиент выпуска, настройки и наблюдение остаётся у владельца сервера. Эти способы нельзя смешивать в одной инструкции без указания площадки.

Что проверяет сертификат

Сертификат позволяет клиенту проверить, что сервер предъявляет удостоверение для запрошенного имени и что цепочка доверия подходит клиенту. Закрытый ключ должен оставаться у обслуживающего узла. Сертификат не подтверждает качество статьи, безопасность прикладного кода или сохранение старых URL. Поэтому наличие значка защищённого соединения — отдельное условие публикации, а не замена остальных проверок.

Представим, что браузер открывает https://staging.example.com, а сервер предъявляет сертификат только для example.com. Общий IP не делает имена взаимозаменяемыми. Тестовое окружение должно иметь своё покрываемое имя, даже если оно закрыто паролем. Аутентификация страницы начинается после установления TLS-соединения и не исправляет ошибку имени сертификата. По аналогичной причине HTTPS-перенаправление с www требует корректного первого соединения.

Nginx связывает сертификат и ключ с серверной конфигурацией посредством отдельных директив. При размещении нескольких имён нужно учитывать выбор серверного блока, а не просто наличие файлов в каталоге. Конкретный пример после подготовки VPS появится в шестом уроке. Документация TLS-модуля Nginx.

Подтверждение контроля над именем

Автоматизированный выпуск через ACME начинается с доказательства контроля над доменом. У Let's Encrypt метод HTTP-01 использует специальный ресурс на порту 80, DNS-01 — TXT-запись в DNS. Эти методы решают разные организационные задачи. HTTP-01 удобен, когда домен уже приходит на нужный сервер и путь проверки можно отдать извне. DNS-01 позволяет подтвердить имя через DNS, но требует аккуратного обращения с доступом к зоне. Способы проверки Let's Encrypt.

Для начального стенда выберем HTTP-01 на VPS, который уже обслуживает имя. Обычные страницы могут перенаправляться с HTTP на HTTPS, однако путь ACME должен оставаться доступным в допустимой схеме проверки. Если staging закрыт серверной аутентификацией целиком, исключение для проверочного пути нужно спроектировать отдельно. Пароль от staging не должен требоваться внешнему центру сертификации. При переносе домена на ещё не опубликованный сервер чаще удобнее заранее подготовить DNS-01.

План для example.com
Имя приходит на подготовленный сервер.
Порт 80 доступен для выбранного способа ACME.
Виртуальный сайт обслуживает путь подтверждения.
Сертификат установлен в его TLS-конфигурацию.
Продление использует тот же работоспособный механизм.

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

Виртуальный хостинг и VPS

На Beget выпуск Let's Encrypt выполняется через инструменты площадки. Для сайта, уже привязанного в панели, это избавляет от самостоятельного управления системными файлами веб-сервера. Однако владелец всё равно проверяет, какие имена включены, правильно ли привязан домен и открывается ли конечный адрес. Не нужно устанавливать Certbot внутри каталога статического сайта в надежде изменить глобальные настройки хостинга. Инструкция Beget по Let's Encrypt.

На Ubuntu VPS можно использовать Certbot с интеграцией Nginx либо другой подходящий ACME-клиент. Последовательность зависит от уже существующей конфигурации и метода подтверждения. Учебный вариант ниже предполагает подготовленный Nginx с нужным server_name, доступный порт и отдельно согласованную установку клиента; это не универсальная команда для любого сервера. Руководство Ubuntu по получению TLS-сертификатов.

sudo certbot --nginx -d example.com
sudo certbot renew --dry-run

Первое действие относится к первоначальному выпуску и настройке, второе проверяет учебный процесс продления. Во время написания команды не выполнялись. Даже успешная проба продления не отменяет необходимости наблюдать реальный срок и ошибки запланированной задачи. Некоторые сбои появляются позднее: изменили DNS, закрыли порт или перенесли путь проверки. Поэтому результат пробного запуска записывают с датой и возвращаются к нему после изменения инфраструктуры.

Продление как часть сопровождения

Не будем зашивать в план универсальный срок жизни сертификата: политика центров и настройки клиентов меняются. Вместо этого наблюдаем фактическую дату окончания установленного сертификата и успешность автоматического продления. Для оповещения полезен запас времени, который позволяет разобраться в причине, а не уведомление в последнюю минуту. Состояние задачи на сервере и внешний сертификат дополняют друг друга: задача могла получить новый файл, который веб-сервер ещё не начал использовать.

Сертификат обновился, но ключ и цепочка должны быть подхвачены обслуживающим процессом. Некоторые инструменты выполняют необходимую перезагрузку конфигурации автоматически, другие требуют отдельно настроенного действия. После продления проверяют внешний ответ выбранного имени. На площадке с несколькими узлами или CDN сертификат может находиться в двух местах: на внешнем слое и на origin. У них разные сроки и разные причины ошибки.

Проверка со стороны посетителя

Обычный запрос к HTTPS должен пройти проверку доверия без отключающих её ключей. Подстановка -k в диагностике скрывает именно то свойство, которое сейчас проверяем. У будущего стенда можно сохранить заголовки и тело ответа отдельно, а затем проверить старую страницу и её ресурсы. Если HTML открывается по HTTPS, но CSS загружается по HTTP, задача ещё не завершена: нужно исправить адрес ресурса в исходниках или конфигурации генерации.

curl --fail-with-body --dump-header headers.txt \
  --output page.html https://example.com/my/legacy/first.php

Ожидается корректное соединение и содержимое старой статьи, а не просто отсутствие ошибки команды. Перенаправления, имя сертификата и тип содержимого интерпретируют вместе. В результате урока у нас есть план первичного выпуска, продления и внешней проверки TLS. Следующим шагом подготовим доступ к VPS, чтобы настройки существовали не только в плане, но и в управляемом окружении будущего стенда.