Автоматическое продление — это обещание, что о сертификатах можно больше не думать. В основном оно это обещание выполняет, и именно поэтому день, когда оно подводит, становится неожиданностью. Вчера сайт работал, а сегодня браузеры показывают предупреждение на весь экран.
Причина в том, что «автопродление» — не одна операция. Для сертификата, выпущенного по распространённому автоматическому протоколу (ACME), которым пользуются Let's Encrypt и другие, каждый раз должны сработать сразу несколько шагов. О том, как вообще устроены сертификаты и как читать их даты, см. статью Как не допустить истечения SSL-сертификата. Это руководство — о случае, когда автоматика была включена, а сертификат всё равно истёк.
Цепочка шагов
- Запускается задача. Что-то выполняется по расписанию: таймер, запись cron или встроенная задача вашего хостинга.
- Клиент продления просит новый сертификат. Он обращается к центру сертификации.
- Центр сертификации проверяет, что имя под вашим контролем. Нужно выполнить проверочное задание, через веб или через DNS.
- Новый сертификат сохраняется в файл или хранилище.
- Сервер его загружает. Многие серверы читают файл только при запуске или при перезагрузке конфигурации.
- Посетители его получают. На каждом адресе, порту и уровне, которые отдают сертификат.
Если шаг 1 так и не выполняется, остальное не важно. Если шаг 5 не происходит, продлённый файл лежит без дела. Любой сбой снаружи выглядит одинаково: старый сертификат истекает.
Где ломается
| Шаг | Что идёт не так | Типичный признак |
|---|---|---|
| 1 | Задачу по расписанию удалили, отключили или не перенесли после миграции сервера либо обновления | Неделями ничего нет в журнале продления |
| 2 | Клиент слишком старый, или его учётная запись либо доступ пропали | Ошибки в журнале продления об учётной записи или запросе |
| 3 | Шаг проверки владения перестал работать: изменённый файрвол, перенаправление, блокирующее путь проверочного задания, изменённая DNS-запись или доступ к API | Ошибка «challenge failed» или «unauthorized» |
| 3 | Слишком много неудачных или повторных запросов упёрлись в ограничение центра сертификации | Сообщение об ограничении частоты; продление не проходит, пока лимит не снимется |
| 4 | Файл не удалось записать, или не сработал обработчик, который его копирует | Новый файл есть в одной папке и отсутствует в другой |
| 5 | Сервер так и не перезагрузили, или он читает не тот файл, который обновляет клиент | У файла новая дата, а браузер показывает старую |
| 6 | Сертификат отдаёт другой уровень: балансировщик нагрузки, CDN, почтовый сервер, другой порт, другой виртуальный хост | Один адрес продлён, другой нет |
Все эти случаи описаны на форумах и в руководствах хостеров. Самые частые истории — задача, которая пропала после какого-то изменения, и сертификат, который продлили, но сервер продолжал отдавать старую копию.
Найдите слабое звено
Идите с конца, потому что именно его видят посетители.
Что отдаётся
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject
Команда выводит даты начала и конца действия сертификата, который сервер отдаёт на этом адресе. Если дата окончания близка или прошла, сертификат не продлён там, где это важно. Запустите её для каждого имени и порта, которыми вы пользуетесь, а не только для основного.
Что лежит на диске
С Certbot список сертификатов и их сроков действия выводится так:
sudo certbot certificates
Если у файла новая дата, а сервер показывает старую, проблема на шаге 5 или 6: сервер не перезагрузили или он читает другой файл. Если старый сам файл, проблема на шагах с 1 по 4.
Запускается ли задача
В системе с таймерами systemctl list-timers выводит список задач по расписанию. Найдите задачу продления и время её последнего запуска. Обычная настройка cron находится в crontab -l и в файлах под /etc/cron.d/.
Работает ли продление сейчас
sudo certbot renew --dry-run
Пробный запуск проходит все шаги, ничего не заменяя. Ошибка здесь — та же ошибка, которая заблокировала настоящее продление, и она называет шаг.
Note
Эти команды рассчитаны на Certbot на сервере с Linux. У других клиентов и панелей хостинга свои инструменты. Порядок остаётся тем же: что отдаётся, что сохранено, запускается ли задача, работает ли продление.
Исправление и профилактика
- Исправьте причину, затем один раз продлите вручную, чтобы не ждать следующего запуска по расписанию.
- Перезагружайте сервер после каждого продления. Большинство клиентов умеют выполнять команду после успешного продления. Без этого продлённый файл может лежать без дела.
- Перечислите все места, где живёт сертификат. Сайт, почтовый сервер, хост API, тестовый хост, балансировщик нагрузки. У каждого нужно своё продление и своя проверка.
- Не доверяйте молчанию самой задачи. Задача, которая тихо падает, выглядит так же, как работающая. Единственное доказательство, что продление сработало, — новая дата у сертификата, который реально отдаётся.
- Держите независимое оповещение. Предупреждение, которое приходит снаружи, заранее до даты окончания, не зависит от того, работает ли какой-либо шаг цепочки.
Что добавляет монитор
Монитор, который подключается к вашему адресу снаружи, читает сертификат, который получили бы посетители. Это шаг 6, единственный шаг, который нельзя подделать изнутри сервера, и он ловит все перечисленные сбои, какой бы шаг их ни вызвал.
UptimeWire примерно каждые шесть часов проверяет сертификат каждого https-адреса и предупреждает вас по почте и в Telegram в пределах выбранного для сайта срока, от 1 до 60 дней до окончания. Предупреждение отправляется один раз. Это напоминание, чтобы вы действовали: UptimeWire не продлевает, не устанавливает и не чинит сертификаты и не выясняет, почему продление не сработало. Он проверяет сертификат для добавленного вами адреса, поэтому другие имена и порты требуют отдельных записей.
Поскольку сертификаты проверяются примерно раз в шесть часов, предупреждение приходит через несколько часов после того, как порог пройден, а не в тот же момент. Для сертификата, который продлевается автоматически, срок предупреждения в 14 или 30 дней служит страховкой: если оно сработало, автоматика уже упустила свой шанс, а у вас ещё есть время исправить всё до того, как пострадают посетители. О том, что делать после получения предупреждения, см. мониторинг срока действия SSL-сертификата.
Чек-лист
- Какой сертификат отдаёт каждый адрес и порт и когда он заканчивается?
- Запланирована ли задача продления и когда она запускалась в последний раз?
- Проходит ли пробный запуск, а если нет — какой шаг он называет?
- Перезагружается ли сервер после продления?
- Продлевается ли каждое имя, поддомен и сервис, которые отдают сертификат?
- Есть ли предупреждение снаружи, настроенное с большим запасом до даты окончания?