Истёкший сертификат — единственная авария, о дате которой известно заранее. Она не приходит неожиданно, не зависит от нагрузки и не связана с чужим сбоем. И тем не менее случается снова и снова, причём в организациях, где всё остальное устроено аккуратно.
Причина не в забывчивости. Причина в том, что обновление обычно устроено как последовательность шагов, и достаточно одному из них молча не сработать.
Что происходит на самом деле
Автоматическое обновление состоит из трёх частей, и обычно настроена только первая.
Получить новый сертификат. Служба обращается к удостоверяющему центру, подтверждает право на домен, забирает файл. Эта часть почти всегда автоматизирована и работает.
Положить туда, где его читают. Файл должен оказаться в каталоге, откуда его берёт сервер или прокси. Если путь изменился при переезде или файл кладётся в том, который перемонтировали, обновление успешно — а сервер продолжает читать старый файл.
Заставить сервер перечитать. Программы читают сертификат при запуске и держат в памяти. Новый файл на диске ничего не меняет, пока не перезагрузили конфигурацию. Именно этот шаг забывают чаще двух других вместе.
Отсюда главное: успешное обновление и работающий сертификат — разные события. Служба обновления рапортует об успехе, а посетитель видит предупреждение.
Тупик: поставить напоминание в календарь
Первое, что делают после аварии, — заводят напоминание за две недели до следующего срока. Ощущение контроля появляется сразу.
Это не помогает по двум причинам. Напоминание приходит человеку, а человек в отпуске, сменил работу или решил, что этим займётся коллега. И оно ничего не проверяет: оно срабатывает по календарю, а не по состоянию.
Вторая частая реакция — «поставим сертификат на год, будет реже». Реже — да, но при этом хуже: процесс, выполняемый раз в год, никто не помнит, документация устаревает, а человек, который его настраивал, к следующему разу обычно уже не здесь. Короткий срок с автоматикой надёжнее длинного вручную именно потому, что поломка обнаруживается на первом же цикле, а не через год.
Что проверять и как
Проверка должна смотреть на то, что видит посетитель, а не на то, что лежит на диске.
Правильная проверка открывает соединение по сети, извлекает срок действия и сравнивает с текущей датой. Она ловит все три отказа сразу: не получили, положили не туда, не перечитали.
Неправильная читает файл на диске. Она скажет, что всё хорошо, ровно в том случае, когда сервер отдаёт старый сертификат из памяти.
Порог предупреждения стоит ставить с запасом: не за день, а за две-три недели. Срок должен быть достаточным, чтобы разобраться в спокойном режиме, а не ночью.
Оповещение должно приходить туда, где его увидят в выходные, и содержать имя домена в первой строке. Письмо на общий ящик с темой из технических сокращений теряется среди прочих.
Проверять надо каждое имя отдельно. Сертификат может покрывать основной домен и не покрывать поддомен, добавленный позже, — и это выяснится, когда поддомен уже смотрит наружу.
Полезно проверять и то, чем сертификат подписан. Удостоверяющие центры меняют промежуточные звенья, и цепочка, собранная год назад, может перестать соответствовать текущей. Это редкий случай, но он даёт ту же картину, что и истечение: у одних работает, у других нет.
Где ломается чаще всего
Подтверждение права на домен. Способ подтверждения перестаёт работать: закрыли служебный путь, поменяли записи в системе доменных имён, добавили правило на прокси, которое перехватывает проверочный запрос. Обновление начинает падать за месяц до срока, и об этом никто не узнаёт, потому что никто не читает журнал успешно работающей службы.
Цепочка сертификатов. Сервер отдаёт только свой сертификат без промежуточных. В браузере с полным набором всё открывается, а мобильное приложение или другой сервис получают ошибку. Диагностика уходит в сторону, потому что «в браузере же работает».
Часы. Сертификат действителен по времени, и рассинхронизированные часы на сервере или у клиента дают ошибку при формально верном сертификате.
Несколько узлов. Обновление отработало на одном сервере, а за балансировщиком их три. Половина посетителей видит ошибку, половина нет, и жалобы выглядят случайными.
Сертификат внутри контейнера. Файл обновился на хосте, но контейнер видит копию, сделанную при сборке образа, или том, примонтированный только для чтения из старого места. Снаружи всё выглядит правильно: на диске новый файл, служба довольна, а отдаётся старый.
Клиентские сертификаты и внутренние службы. Они истекают так же, но их никто не проверяет: внешние проверки смотрят на публичные адреса. Обрыв внутреннего обмена между сервисами по истёкшему сертификату диагностируется дольше всего, потому что публичный сайт при этом работает.
Что сделать один раз
Автоматическое обновление плюс автоматическая перезагрузка конфигурации — обязательно вместе, одним действием. Обновление без перезагрузки не является обновлением.
Внешняя проверка срока по сети, а не по файлу, с предупреждением за две-три недели и адресом, который читают.
Список всех имён, у которых есть сертификаты, в одном месте. Обычно оказывается, что их больше, чем помнят, и часть обслуживается вручную.
Собрать такой список проще, чем кажется: пройдите по записям в системе доменных имён и проверьте каждое имя, отвечающее по защищённому соединению. Обычно всплывают адреса, заведённые под разовую задачу и оставшиеся жить, — именно они истекают первыми, потому что о них не помнит никто.
Запись в журнал о неудачном обновлении, приводящая к оповещению. Тихо падающая автоматика опаснее её отсутствия: при отсутствии хотя бы помнят, что надо делать руками.
И проверка самой проверки. Раз в полгода стоит убедиться, что оповещение доходит: подставить заведомо истекающий адрес или временно снизить порог. Молчащий монитор и работающий монитор выглядят одинаково ровно до того дня, когда разница становится важной.
Позиция редакции
Мы считаем, что проверять надо по сети и снаружи, а обновление и перезагрузку конфигурации считать одним неделимым действием. Практический вывод: если ваша проверка читает файл на диске, она не поймает самый частый случай — сервер, держащий старый сертификат в памяти.
Мы неправы, если сертификатами занимается управляемая платформа, где обновление и подхват — её обязанность: там внешняя проверка остаётся полезной как страховка, а всё остальное лишнее.