Документация

TLS/SSL-монитор открывает TLS-соединение с хостом и портом, читает сертификат, который отдал сервер, и предупреждает до его истечения. Он не отправляет ни одного прикладного байта — ни HTTP-запроса, ни почтовой команды — поэтому работает с любым сервисом, который поднимает TLS с первого байта.

Сертификаты — это не про HTTP. Тот же сертификат с тем же сроком годности стоит перед почтой (SMTPS на 465, IMAPS на 993), каталогами (LDAPS на 636), брокерами сообщений (AMQPS на 5671), IoT (MQTTS на 8883), кэшами и базами поверх TLS (Redis на 6380), gRPC, защищёнными вебсокетами и любым своим бинарным протоколом. Рукопожатие у них одно и то же — поэтому один тип монитора закрывает их все.

Про название. Самого SSL давно нет: SSLv3 объявлен устаревшим в 2015 году, а работает сегодня TLS 1.2 или TLS 1.3. Но сертификаты в обиходе название не сменили, поэтому удостоверяющие центры до сих пор продают «SSL-сертификаты», а в любом сервисе мониторинга есть SSL-проверка. Поэтому монитор и в интерфейсе, и здесь называется TLS/SSL: сначала TLS, потому что по проводу работает именно он, и только потом SSL, потому что это слово всё ещё ищут. Там, где разница важна, на этой странице написано TLS.

TLS/SSL-монитор или HTTPS-монитор?

За сертификатом следят оба, но отвечают на разные вопросы. HTTPS-монитор снимает дату окончания с того самого соединения, которым проверяет сайт, и внутри критического окна сам шлёт оповещение «Сертификат истекает». TLS/SSL-монитор не говорит ни на одном прикладном протоколе, поэтому достаёт до сервисов, куда HTTP-запрос не дойдёт, и записывает сертификат целиком, а не только его даты. Пара «HTTPS + TLS/SSL на одном хосте» перестала быть обязательной — если второй монитор заведён только ради отсчёта дней, его можно удалить и освободить слот тарифа. Ниже — что даёт каждый и когда TLS/SSL-монитор по-прежнему нужен.

Полный список сервисов и портов, с которыми работает TLS/SSL-монитор, — в следующем разделе.

С какими сервисами работает

TLS/SSL-монитор работает с любым сервисом, который поднимает TLS сразу при подключении, на любом порту:

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

С чем не работает

Некоторые сервисы не отдают TLS с первого байта. Они начинают в открытом виде, а клиент просит перейти на шифрование командой вроде STARTTLS. Такие сертификаты TLS/SSL-монитор прочитать не может: он пытается начать TLS сразу, а сервер в этот момент ещё говорит открытым текстом. Почти у всех есть парный порт, который отдаёт TLS сразу, — наводите монитор на него.

Если порта со сразу-TLS у сервиса нет вообще, оповещать об истечении его сертификата в PingZen сейчас нечем. SMTP-монитор на 587 подтвердит, что STARTTLS ещё предлагается и сервер отвечает, но даты сертификата не покажет.

Что проверяется

На каждой проверке TLS/SSL-монитор читает сертификат и проверяет его:

1. Дни до истечения — из поля notAfter
2. Срок жизни сертификата — notAfter минус notBefore, используется для подстройки порогов (см. ниже)
3. Валидность цепочки — сертификат должен быть подписан доверенным центром
4. Совпадение имени хоста — проверяемый хост должен быть в списке SAN сертификата
5. Издатель, субъект и список SAN — показываются на странице монитора
6. Версия TLS и шифр — записываются на каждой проверке

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

Пороги срока действия

Когда монитор реагирует, определяют две настройки:

По умолчанию стоит 14 дней, а не 30, потому что Let’s Encrypt обновляет 90-дневный сертификат, когда до конца остаётся 30 дней. Порог в 30 дней срабатывал бы на каждом здоровом обновлении.

Жёлтый статус и оповещение — разные вещи. Монитор желтеет сразу, как начинается окно предупреждения, а письмо или сообщение в Telegram приходит только внутри критического окна. Жёлтый бейдж без письма — это ожидаемое поведение, а не баг.

Ограничение по сроку жизни сертификата

Сертификаты становятся короче. Let’s Encrypt уже выдаёт шестидневные сертификаты, а CA/Browser Forum проголосовал за снижение максимума до 47 дней к 2029 году. Фиксированный порог «предупредить за 7 дней» держал бы шестидневный сертификат в критическом окне постоянно.

Поэтому PingZen ограничивает оба порога сроком жизни самого сертификата:

• порог предупреждения не превышает трети срока жизни
• критический порог не превышает одной шестой срока жизни

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

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

Что означает каждый статус

Настройки

Оповещения

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

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

Ключевые возможности

• Читает сертификат, не отправляя прикладных данных, поэтому работает на любом TLS-порту
• Пороги предупреждения и критического уровня сами подстраиваются под короткоживущие сертификаты
• Проверяет валидность цепочки и совпадение имени хоста на каждой проверке, а не только срок
• Показывает издателя, субъект, список SAN, версию TLS и шифр
• Показывает данные сертификата даже при провале проверки, видно, что именно отдал сервер
• Жёлтый статус не стоит аптайма: истекающий сертификат — предупреждение, а не авария