Короткий ответ

Браузер админа с «доверенным» кэшем — не мониторинг. Нужен item, который снимает сертификат с нужного SNI (zabbix.example, не IP 10.0.20.50 без имени), парсит дату, триггер «осталось < 21 дня» и ещё один на «цепочка/невалид». На Agent 2 ключ web.certificate.get[host,port] (JSON). HTTP agent / внешний скрипт — запасной путь. Не путать с сроком домена (WHOIS/RDAP ≠ TLS). Невалидный ключ: unsupported.

PSK агента psk-ws042 здесь ни при чём, если item выполняется на сервере/прокси как HTTP agent; если ключ агента на WS-042 — агент должен достучаться до цели с этой машины.

Симптомы и как отличить

Типичная картина:

  • пользователи ERR_CERT_DATE_INVALID, Zabbix тишина;
  • item есть, но JSONPath не тот — unsupported;
  • проверяете 10.0.20.50:443, сертификат default_server, не zabbix.example;
  • Let’s Encrypt 90 дней, порог 7 дней, выходные съели запас.

Отличия:

СбойНе «item TLS»
Сайт 502frontend
Домен не резолвитсяDNS, доступность
Домен expired в регистраторесрок домена
Триггер не считаетсятриггер

Возможные причины

  1. Нет item вообще — «думали, что в шаблоне веб-сервера есть».
  2. Ключ не у той версии агента (agent 1 без plugin).
  3. Preprocessing JSONPath к полю, которого нет в 6.0 vs 7.0 JSON.
  4. Проверка localhost HTTP, прод на другом балансире.
  5. Порог 1 день, media только в рабочие часы.
  6. Item на IP, wildcard/SNI другой.
  7. Редко: TLS 1.3-only, старый openssl на стороне внешнего скрипта; клиентский сертификат на порту.

Диагностика

1. Какой cert реально отдаётся

С 10.0.20.50 или с агента, который будет опрашивать:

echo | openssl s_client -connect 10.0.20.50:443 -servername zabbix.example 2>/dev/null |
  openssl x509 -noout -dates -subject -issuer

Сверьте notAfter с календарём. Если без -servername даты другие — вы уже нашли баг мониторинга по IP.

2. Ключ Agent 2

Документированный ключ Agent 2: web.certificate.get[<hostname>,<port>,<address>]. Пример духа:

zabbix_get -s 10.0.20.42 -p 10050 -k 'web.certificate.get[zabbix.example,443,10.0.20.50]' \
  --tls-connect psk --tls-psk-identity psk-ws042 \
  --tls-psk-file /etc/zabbix/psk-ws042.psk

Если агент на самом zabbix.example, hostname/address подставьте так, чтобы SNI и TCP совпали с прод-путём (через LB — IP LB). Пустой/ошибка — plugin, Allow, сеть с WS-042 на 443.

3. Item в UI

Type: Zabbix agent / agent 2; preprocessing: JSONPath к полю даты (смотрите фактический JSON, не статью 2019). Dependent items: дни до истечения, issuer, fingerprint.

Type of information: text для JSON, numeric для вычисленного TTL.

4. Триггер

Дни < 21 Warning, < 7 High. Не только «cert invalid». Invalid часто уже поздно для закупки.

Решение

Сценарий A. Нет item

Добавьте шаблон «Website certificate by Zabbix agent 2» или ручной item на каждую критичную endpoint (zabbix.example:443, OWA, VPN, API). Список с CMDB, не «главная компания».

Сценарий B. Неверный SNI/IP

Параметры ключа: hostname = SNI zabbix.example, address = куда TCP (LB). Мониторьте внешний путь, которым ходят пользователи, плюс внутренний если разные cert.

Сценарий C. JSONPath

Test preprocessing на живом JSON. Поле даты может быть unix time — тогда функция time() сравнения. Не держите JSON в trigger без dependent numeric.

Сценарий D. Agent 2 недоступен до цели

Исходящий 443 с хоста агента. Если агент не должен ходить наружу — HTTP agent на server/proxy 10.0.20.50 (тип item HTTP agent / browser в 7.0 по возможности). Не открывайте мир до WS-042 ради cert check.

Сценарий E. Пороги и календарь

21/14/7 дней, escalation на почту PKI. Для Let’s Encrypt 90d — Warning 21 обязателен. Автопродление: алерт если notAfter не отодвигается после cron.

Windows LDAPS/winrm cert: см. Windows Server — отдельно от веб-SNI.

Как проверить, что проблема устранена

Latest data: notAfter в будущем, TTL дни совпадают с openssl. На стенде с cert на 10 дней — Warning. Action log: письмо. Смена cert — значение item обновилось за интервал (1h достаточно, не 10s). Пользовательский браузер — не единственный критерий, но smoke после замены.

Если не помогло

  • Мониторите nginx, пользователи на Cloudflare — другой cert на edge. Item должен бить в edge hostname.
  • Internal CA: агент не доверяет, item падает — это валидность цепочки, отдельный триггер, не выключайте проверку глобально.
  • IP SAN only, SNI пустой — документируйте и проверяйте тот режим, что клиент.

Профилактика

  • Реестр сертификатов: сервис, SNI, кто продлевает, item name.
  • Алерт на unsupported самого cert-item.
  • Не выпускать cert без добавления мониторинга в том же изменении.
  • Связка с доменом: expiry домена раньше cert — оба алерты.

Составьте перечень endpoint, а не «главный сайт». Обычно забывают SMTP STARTTLS, IMAP, LDAPS, VPN-портал, API на другом имени, внутренний zabbix.example и внешнее имя на CDN. Каждый — свой item и свой SNI. Один web.certificate.get на IP 10.0.20.50 без servername закрывает только default_server nginx.

Let’s Encrypt на 90 дней требует Warning за 21 день, иначе пятничный expiry всплывает в понедельник. Автопродление не отменяет контроль: полезен триггер «notAfter не сдвинулся после известного cron». Если certbot кладёт файл не в тот каталог, которым пользуется nginx, handshake и файл на диске разъедутся.

Смена балансира без смены item даёт зелёный мониторинг и красный браузер. После миграции TLS повторите openssl s_client -servername и с 10.0.20.50, и с сети клиентов.

FAQ

web.page.regexp вместо certificate.get?

Парсить HTML нет смысла для expiry. Нужен handshake TLS.

Можно ли cron openssl и zabbix_sender?

Да, как запас. Штатный ключ агента 2 проще в 6.0/7.0, если plugin есть.

Почему IP 10.0.20.50 показывает другой cert?

default_server. Всегда ServerName.

Клиентский сертификат на API

web.certificate.get смотрит серверный cert. Клиентский — другой контроль.

Нужен ли алерт на отпечаток?

Полезен против тихой подмены. Warning при смене fingerprint, если смена не из вашего окна работ.

STARTTLS SMTP/IMAP

Не HTTP порт. Используйте соответствующий ключ/скрипт openssl s_client -starttls smtp. Не считайте, что шаблон веб-сайта покрыл почту.