Мониторинг истечения TLS-сертификатов на всех узлах, а не только на основном сайте

Цель

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

Предварительные условия

Инвентарь имён хостов и портов, на которых терминируется TLS (443, а также SMTP, IMAP, LDAP, порты баз данных, административные панели, листенеры балансировщиков, конечные точки VPN); система мониторинга, выполняющая проверки по расписанию; знание того, как выпущен каждый сертификат (клиент ACME, управляется провайдером, вручную).

Шаги

1. Стройте инвентарь по тому, что реально обслуживается, а не по тому, что задокументировано: сканируйте принадлежащие организации адреса и DNS-имена на предмет TLS-листенеров и фиксируйте хост, порт, subject и issuer.
2. Для каждого узла опрашивайте его снаружи хоста и считывайте цепочку так, как её видит клиент. RFC 5280 определяет период действия через notBefore и notAfter; у листового сертификата и у каждого промежуточного — свои собственные значения.
3. Вычисляйте число дней до notAfter для листового и промежуточных сертификатов и экспортируйте его как метрику. Для скрипта в руководстве OpenSSL описана команда openssl x509 -checkend <seconds>, которая завершается с ненулевым кодом, если сертификат истекает в пределах указанного числа секунд; в руководстве версии 3.6 добавлен флаг -multi, при котором -checkend завершится с ошибкой, если в пределах периода истекает любой сертификат во входных данных (например, в сохранённой цепочке). В руководстве версии 3.5 флага -multi нет, поэтому на более старых версиях листовой и промежуточные сертификаты нужно проверять по отдельности.
4. Задавайте порог оповещения относительно механизма выпуска. Let's Encrypt указывает, что сертификаты по умолчанию действительны 90 дней и рекомендует продлевать их каждые 60 дней, а короткоживущие сертификаты действительны шесть дней с продлением каждые три дня. Для 90-дневного случая продление на 60-й день оставляет ещё 30 дней в запасе; поэтому оповещение при 20 оставшихся днях означает, что автоматическое продление уже пропустило цикл, а у человека время ещё есть. Для шестидневных сертификатов порог нужно измерять в часах.
5. Оповещайте также при сбое самой проверки (порт закрыт, ошибка при handshake) и при сертификате, чей subject или issuer отличается от ожидаемого.
6. Проверьте оповещение, опросив заведомо короткоживущий сертификат или подняв порог выше текущего числа оставшихся дней для одного из узлов.
7. Зафиксируйте для каждого узла, кто и как его продлевает; сценарий реагирования на оповещение — «выполнить продление, затем перепроверить».

Ожидаемый результат

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

Ограничения и основание проверки

Проверка изнутри хоста пропускает сертификаты, которые предъявляет балансировщик нагрузки или CDN перед ним. Клиентским сертификатам и сертификатам для подписи кода нужен тот же инвентарь, но другие проверки. Сроки действия приведены по заявлениям указанных удостоверяющих центров; никакой статистики отказов не утверждается.