Обеспечьте работу HTTPS на протяжении всего жизненного цикла сертификата
Браузер, показывающий сегодня защищённое соединение, — это начало работы с сертификатами, а не её конец. Домен может переместиться, путь проверки может измениться, а продление может пройти успешно, хотя публичный сервис не загрузит новый сертификат. Рассматривайте выпуск, развёртывание и дальнейшую проверку как отдельные шаги с чётко назначенным ответственным.
Практический вывод
Знайте каждую точку завершения TLS, автоматизируйте продление подходящим методом проверки, протестируйте этот процесс и убедитесь, что после развёртывания пользователям действительно отдаётся нужный сертификат.
Составьте карту точек завершения защищённого соединения
Перечислите имена хостов, которые пользователи действительно посещают, включая основной домен, имя www, поддомены приложений и важные конечные точки API. Затем определите, где для каждого из них завершается TLS: веб-сервер, обратный прокси, балансировщик нагрузки или другой управляемый сервис. Сертификат, установленный на источнике, не доказывает, что отдельный публичный прокси отдаёт тот же самый. Храните эту опись у людей, отвечающих за домены и доступ к хостингу.
Сертификат должен покрывать имя хоста, запрошенное клиентом, и выстраиваться в цепочку до доверенного корневого сертификата, который принимает этот клиент. Сервис также должен корректно предъявлять соответствующий сертификат и промежуточную цепочку. Проверяйте не один удобный URL, если приложения используют несколько имён. Успешное соединение с основным доменом мало что говорит о поддомене API или отдельном почтовом сервисе, у которых может быть собственный процесс работы с сертификатами.
HTTPS защищает соединение в рамках применимого протокола и конфигурации; это не доказательство отсутствия уязвимостей в приложении и не свидетельство надёжности продавца. Контроль доступа, обновления и резервные копии должны входить в отдельный план эксплуатации. Список возможностей веб-хостинга HM Bastion включает автоматическое продление SSL, тогда как администратор VPS должен самостоятельно убедиться в наличии и настроить инструменты работы с сертификатами в своём стеке. Не предполагайте, что эта ответственность одинакова.
Выбирайте проверку с учётом среды, в которой работаете
ACME автоматизирует действия по получению сертификатов, включая подтверждение контроля над запрошенными доменными именами. Разные методы проверки подходят для разных сред. Проверка на основе HTTP зависит от доступности требуемого пути проверки в соответствии с указаниями удостоверяющего центра. Проверка на основе DNS зависит от контроля над соответствующими записями DNS. Перед выбором метода изучите документацию удостоверяющего центра и клиента, особенно если перед источником стоит прокси или несколько экземпляров приложения.
| Эксплуатационный вопрос | Что нужно определить |
|---|---|
| Кто контролирует DNS? | Назначенный ответственный и необходимый доступ для проверки |
| Куда могут поступать запросы проверки? | Публичная маршрутизация и обработка проверочных запросов для каждого соответствующего имени |
| Как хранятся учётные данные? | Приватное хранилище и минимально необходимые разрешения |
| Что происходит после выпуска? | Развёртывание в нужный сервис и проверенная перезагрузка |
Автоматизация DNS может требовать учётных данных со значительными правами на домен. Храните их вне публичных каталогов и, если это поддерживается, предоставляйте только те разрешения, которые нужны выбранной интеграции. Ведите отдельную документацию процесса, не смешивая её с самими секретными значениями. Ручная проверка может подходить для конкретной конфигурации, но она создаёт постоянную зависимость от человека; запишите, кто будет её выполнять и как будет замечено приближение срока продления.
При тестировании интеграции используйте тестовую среду удостоверяющего центра, если она доступна. Это позволяет отработать процесс, не превращая повторный выпуск в рабочей среде в способ отладки. Тестовый сертификат не является доверенным для обычного публичного сервиса, поэтому сохраняйте ясность цели теста. Избегайте жёстко зашитых допущений о сроках действия сертификатов или графиках продления, если удостоверяющий центр и клиент предоставляют указания или сведения о продлении, которые могут измениться.
Продление, развёртывание и перезагрузка — это разные результаты
Убедитесь, что механизм планового продления действительно запускается под нужной учётной записью и в нужной среде. Команда, работающая в интерактивном терминале, может зависеть от пути, разрешения или учётных данных, отсутствующих при её плановом выполнении. Просмотрите соответствующие журналы и используйте поддерживаемую клиентом процедуру проверки продления. Для Certbot документация описывает тестовый запуск и хуки продления; следуйте инструкциям, соответствующим установленной версии и выбранному методу аутентификации.
Только что созданный файл сертификата не меняет автоматически то, что предъявляет работающий сервис. Сервису может потребоваться перезагрузка, хук развёртывания или распространение на несколько точек завершения. Проверьте конфигурацию перед перезагрузкой, сохраните путь отката и проверьте публичное соединение после этого. В многоузловой конфигурации один успешный запрос может попасть только на один узел. Запланируйте проверку, охватывающую фактическое развёртывание, вместо предположения, что все экземпляры изменились одновременно.
Отслеживайте сертификат, предъявляемый извне, охватываемые им имена и оставшееся до истечения время. Это выявляет сбой, отличный от проверки того, успешно ли завершилась задача продления. Поддерживайте актуальность ответственных за уведомления, в том числе при смене агентства или администратора. Оповещение, доставленное на заброшенный почтовый ящик, даёт мало защиты. Пересматривайте инвентаризацию после изменения DNS, добавления обратного прокси, перемещения имени хоста или изменения конфигурации веб-сервера.
Разбирайте неудачное продление начиная с шага, на котором произошёл сбой
- Зафиксируйте затронутое имя хоста, версию клиента, время и точную ошибку без секретных данных.
- Определите, относится ли сбой к валидации, выпуску, развёртыванию или публичному обслуживанию.
- Проверьте соответствующие DNS, маршрутизацию, доступ к файлам и окружение запланированной задачи.
- Устраните и проверьте узкую причину, прежде чем повторять выпуск в рабочей среде.
- После восстановления проверьте публичный сертификат и обычные сценарии работы приложения.
Например, если валидация не проходит после изменения DNS, сравните текущие публичные записи с предполагаемым маршрутом проверки, прежде чем заменять инструменты работы с сертификатами. Если выпуск успешен, но браузер по-прежнему видит старый сертификат, проверьте публичную точку завершения и процесс развёртывания. Повторные запросы сертификатов не исправят прокси, который читает другой файл. Сохраняйте исходную ошибку и последующие действия в хронологии, чтобы следующий человек мог проследить диагностику.
Если закрытый ключ мог быть скомпрометирован, рассматривайте это как инцидент безопасности, а не как обычное напоминание об истечении срока. Реакция может включать замену ключей, отзыв затронутых сертификатов через надлежащий процесс и расследование компрометации. Никогда не помещайте закрытый ключ или учётные данные DNS в заявку в поддержку. Передайте имя хоста, идентификаторы сертификатов, где это полезно, и безопасный диагностический вывод, чтобы команда могла провести расследование, не получая контроля над доменом.
