Настройка Let's Encrypt с автоматическим обновлением SSL

Сертификат Let's Encrypt истёк ночью: что ломается

Истёкший сертификат Let's Encrypt проявляется не постепенно, а сразу: браузеры перестают открывать соединение и показывают предупреждение о небезопасном сайте. Пользователь не станет разбираться, кто виноват, — он уходит. Если на домене висят оплата, вход в личный кабинет или форма заявки, отказ приходит вместе с ошибкой SSL: платёжный шлюз отклоняет запрос, авторизация не проходит, заявки не доходят. Ночью это выглядит как «сайт лёг», хотя сервер и приложение живы.

Причина почти всегда одна: автопродление не сработало, а узнали об этом из письма клиента, а не из мониторинга. Let's Encrypt выдаёт сертификаты на короткий срок и рассчитан на автоматическое обновление — ручной контроль здесь не работает по определению. Типовые сбои: задача обновления стоит в планировщике, но падает молча; проверка домена перестала проходить после смены DNS или переезда; веб-сервер не перечитывает конфигурацию и продолжает отдавать старый файл; на нескольких узлах обновился только один.

Отдельный случай — лимиты на повторную выдачу: после нескольких неудачных попыток запрос блокируется на время, и «просто перезапустить» уже не помогает.

Цена такого простоя выше, чем кажется. Ночное окно — это потерянные заказы и брошенные корзины, утренний пик — репутация в поиске и у пользователей, которые запомнили предупреждение и не вернулись. Хуже всего, что сбой повторяется: если обновление не поставлено на надёжные рельсы, через тот же срок всё повторится.

Закрывается это не разовой заменой файла, а схемой: автопродление с запасом по времени, проверка фактического срока действия на всех узлах, оповещение за дни до истечения и автоматический откат, если обновление не прошло. Тогда сертификат перестаёт быть точкой отказа, о которой вспоминают только в момент аварии. Разбираем, как это устроить.

Что даёт автоматическое обновление сертификатов

Автоматическое обновление убирает целый класс отказов, который раньше жил в календаре дежурного инженера. Сертификат — это файл с датой окончания, и пока продление остаётся ручной операцией, рано или поздно чей-то отпуск, смена или забытый тикет совпадут с этой датой. Браузер в ответ покажет предупреждение о небезопасном соединении, и сайт формально работает, но пользователь видит его сломанным.

С автоматическим продлением срок перестаёт быть точкой риска. Клиент Let's Encrypt выдаёт сертификаты на короткий период, поэтому обновление запускается заранее, до истечения, и проходит без участия человека. Если продление по какой-то причине не удалось — недоступен сервер проверки, изменилась конфигурация веб-сервера, — задача падает с ошибкой и уходит уведомление, а не молчаливое «всё хорошо». Это переводит проблему из разряда «узнали от клиентов» в разряд «узнали из мониторинга».

Время восстановления при этом меняется принципиально. Раньше выпуск и установка нового сертификата занимали от нескольких минут до часов: нужно было вспомнить процедуру, получить доступ, перезагрузить сервис, проверить цепочку. Теперь откат или перевыпуск — это повторный запуск автоматики, то есть минуты, и он не зависит от того, кто именно сегодня на связи.

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

Надёжность здесь — не про «сертификат точно есть», а про предсказуемость. Мы проверяем, что продление действительно срабатывает, а не только настроено: прогоняем сценарий на тестовом окружении, следим за сроком действия через мониторинг и держим запас по времени до истечения. Тогда единственный оставшийся риск — внешний сбой на стороне центра сертификации, и на него есть понятный план действий.

Способы выпуска и проверки: сравнение подходов

Выбор способа выпуска и подтверждения домена определяет, насколько автономно сертификат будет продлеваться дальше. Ошибка на этом этапе проявляется не сразу, а через 60-90 дней, когда срок действия подходит к концу и продление падает молча. Ниже — рабочие варианты, между которыми реально выбирают на практике.

Режимы работы

Ключевая развилка — где живёт клиент и как он получает продление. В режиме standalone клиент поднимает свой порт на время проверки, поэтому веб-сервер нужно останавливать — это допустимо на изолированном узле, но ломает работу при живом трафике. В режиме webroot проверка идёт через уже работающий сервер, продление не рвёт соединения, но требует, чтобы путь до корня сайта был доступен процессу. В режиме DNS-01 порт вообще не нужен — это единственный путь для wildcard и для серверов за балансировщиком.

Ограничения, которые стоит учесть заранее

У Let's Encrypt есть лимиты на количество выпусков для одного домена за период и на повторные неудачные проверки — при массовом развёртывании это упирается в квоту, если не кэшировать промежуточные результаты. Сертификат живёт 90 дней, продление запускают за 30 дней до конца: этого запаса хватает, чтобы поймать сбой и не уйти в просрочку. Для внутренних доменов без публичной зоны DNS-01 остаётся единственным рабочим вариантом.

Как мы внедряем автоматизацию: этапы работ

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

1. Аудит конфигурации. Собираем текущие сертификаты, сроки их действия и способ выпуска. Проверяем, покрыты ли все имена, включая те, что добавляли вручную и забыли внести в автоматику.
2. Схема продления. Определяем, где будет жить клиент обновления, как он получает подтверждение владения доменом и куда складывает готовые сертификаты. Фиксируем единую точку, чтобы не было двух конкурирующих процессов.
3. Настройка автоматического обновления. Прописываем регулярную задачу с запасом по времени до истечения срока, добавляем перезагрузку сервисов, которые держат сертификат в памяти, и уведомления о неудачных попытках.
4. Проверка. Прогоняем выпуск на тестовом контуре, затем проверяем реальное продление и откат на предыдущий сертификат. Смотрим, что цепочка доверия собирается корректно и старые браузеры не отваливаются.
5. Мониторинг. Настраиваем контроль срока действия и алерты за несколько дней до истечения — чтобы проблема всплывала у нас, а не у посетителей.
6. Передача. Отдаём конфигурации, схему размещения и инструкцию по добавлению новых доменов, чтобы команда заказчика могла расширять список без нас.

Каждый этап заканчивается проверяемым результатом, а не отчётом. После передачи сертификаты продлеваются сами, а ручное вмешательство требуется только при добавлении новых доменов.

Что заказчик получает на руки после работ

Работы заканчиваются не фактом «сертификат выпущен», а передачей комплекта, по которому ваша команда или другой подрядчик сможет эксплуатировать и восстанавливать схему без нас. Ниже — что именно фиксируется в документации и конфигурации.

• Конфигурации выпуска и продления — итоговые файлы веб-сервера и клиента Let's Encrypt с выпущенными сертификатами, включая параметры проверки домена и цепочку промежуточных сертификатов.
• Схема автоматического обновления — где живёт задача продления, как она запускается, что происходит при неудаче и как приходит уведомление об истечении срока.
• Схема маршрутизации трафика — как запросы проверки домена доходят до нужного сервиса, что настроено на балансировщике и где заканчивается защищённый участок.
• Политики доступа — какие учётные записи и ключи имеют право выпускать и отзывать сертификаты, кто и как получает доступ к приватным ключам.
• Регламент обслуживания — периодичность проверки сроков действия, порядок действий при сбое продления и при плановом переезде на другой сервер.
• Инструкция по восстановлению — пошаговый сценарий: как заново выпустить сертификат, если конфигурация потеряна или сервер пересоздан с нуля.
• Журнал изменений — какие домены и поддомены покрыты, когда менялись параметры, кто вносил правки.

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

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

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

Что было до

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

Что изменили

Настроили автоматическое продление через Let's Encrypt с проверкой владения доменом и перевыпуском задолго до истечения срока. Добавили отдельную проверку: если сертификат не обновился или истекает раньше контрольного срока — приходит уведомление дежурному, а не клиенту. Ручные операции с файлами и перезапуском сервера убрали полностью.

Что стало

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

Чем отличается Let's Encrypt от платных сертификатов?

С точки зрения браузера разницы нет: Let's Encrypt — обычный DV-сертификат от доверенного удостоверяющего центра, чей корневой сертификат предустановлен в операционных системах и браузерах. Соединение шифруется одинаково, зелёный замок и HTTPS отображаются так же. Пользователь не увидит, платный сертификат или автоматически выпущенный, — он увидит только, что сайт защищён.

Ключевое отличие — срок действия и модель выпуска. Платные сертификаты выдают на год и больше, Let's Encrypt — на короткий период, поэтому обновление обязано быть автоматическим. Это не недостаток, а дисциплина: короткий срок означает, что при компрометации ключа окно риска измеряется днями, а не месяцами. Ручное обновление здесь просто не работает — забыли продлить, и сайт встречает посетителей предупреждением о небезопасном соединении, что бьёт по доверию и позициям в поиске.

По уровню доверия разница проявляется в сценариях. Бесплатный DV-сертификат подтверждает только владение доменом — этого достаточно для сайтов, интернет-магазинов, личных кабинетов и API. Платные OV и EV дополнительно проверяют организацию и показывают её в сертификате: это востребовано в банках, госсекторе, платёжных шлюзах, где важна юридическая идентификация. Если ваш сценарий — обычный веб-сервис, разницы в доверии для клиента нет.

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

Выбор определяется сценарием: где нужна проверка организации — берут платный, где важны автоматизация и отсутствие простоев — Let's Encrypt. Мы настраиваем выпуск и автообновление так, чтобы продление шло без вмешательства и без падения доступности.

Частые технические сомнения по настройке SSL

Сомнения обычно одни и те же: «у нас уже есть сертификаты от другого центра — придётся всё ломать?», «домены десятками, это ручная работа?», «внутренние сервисы вообще нельзя выпускать наружу». Разбираем по порядку — это ровно те места, где настройка Let's Encrypt либо проходит гладко, либо превращается в простой.

Доменов несколько — это ручная работа для каждого?

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

Внутренние сервисы не должны быть доступны извне — как быть?

Для внутренних сервисов используем подтверждение через DNS-запись: она доказывает владение доменом, не открывая сервис наружу. Так закрытые панели, тестовые контуры и служебные адреса получают валидный сертификат, оставаясь недоступными из интернета. Проверка владения проходит на стороне DNS-провайдера, а сам сервис продолжает жить во внутренней сети.

Совместимость со старыми клиентами и мобильными приложениями

Сертификаты Let's Encrypt доверенные для подавляющего большинства современных браузеров и мобильных платформ. Проблемы возникают только на устаревших устройствах, где корневой сертификат не обновлялся годами. Перед миграцией мы проверяем, какие клиенты реально ходят на ваш сервис, и если среди них есть такие — оставляем для них отдельный узел со старым сертификатом, пока парк не обновится.

Каждое из этих сомнений закрывается на этапе проектирования, а не в момент сбоя. Опишите вашу схему — сколько доменов, есть ли внутренние сервисы, какой центр сертификации используется сейчас, — и мы вернёмся с оценкой и планом перехода.

Обсудим вашу задачу и вернёмся с оценкой

Чтобы вернуться с оценкой, а не с общими словами, нам нужен срез вашей текущей конфигурации: где терминируется TLS, кто выдаёт сертификаты, как устроена балансировка и что уже настроено в автоматическом обновлении. По этим вводным мы предложим план работ и оценку — без обязательств с вашей стороны и без «уточним позже».

Что описать в заявке, чтобы разговор был предметным:

• Где сейчас живут сертификаты: на одном сервере, на балансировщике, в обратном прокси или раздаются по нескольким узлам.
• Как выпускаются и продлеваются: вручную, по расписанию, через отдельный сервис управления сертификатами.
• Сколько доменов и поддоменов в периметре, включая служебные и staging-контуры.
• Что уже ломается: истёкшие сертификаты, рассинхрон между узлами, ручные напоминания, ошибки при продлении.
• Ограничения инфраструктуры: закрытые контуры без внешнего доступа, собственный центр сертификации, требования по доступам.
• Кто отвечает за эксплуатацию и какие окна для изменений допустимы.

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

Следующий шаг простой: пришлите описание конфигурации в свободной форме или ссылку на схему. Мы разберём её, зададим уточняющие вопросы и вернёмся с оценкой и планом работ по настройке Let's Encrypt с автоматическим обновлением.