Настройка мониторинга SSL-сертификата и уведомлений в 2026

Я обычно настраиваю мониторинг SSL-сертификатов сразу вместе с uptime-контролем, а не «потом, когда будет время». Иначе в один прекрасный день вы ловите просроченный сертификат, падающий HTTPS, просадку доверия и лишний стресс у всей команды.

В 2026 году история с SSL уже не про «поставили Let’s Encrypt и забыли». На деле сертификат нужно не только выпустить, но и отслеживать: срок действия, цепочку, корректность SAN, автопродление, ошибки nginx/Apache, проблемы с DNS, а ещё доставку уведомлений в Telegram, почту, Slack или WhatsApp через внешние интеграции. У меня был клиент на WordPress, у которого сертификат обновлялся автоматически, но webhook уведомлений молчал три недели. Сертификат успел уйти в красную зону, а они узнали об этом от отдела продаж. Это плохая идея.

Зачем мониторить SSL в 2026 году

Честно говоря, многие до сих пор думают, что SSL — это история «настроил один раз и забыл». На практике так работает только на очень маленьких проектах без нагрузки, без мультидоменности и без постоянных обновлений. Если у вас Bitrix, WordPress, Laravel, CDN, reverse proxy, несколько поддоменов или staging-среда, сертификаты начинают жить своей жизнью. И если это не держать под контролем, проблемы вылезают в самый неудобный момент.

В 2026 году браузеры ещё жёстче реагируют на некорректный HTTPS. Если у сайта просрочен сертификат, часть пользователей просто не пойдёт дальше предупреждения. Если цепочка выдачи сломана, мобильные устройства могут показывать странные ошибки. Если сайт работает через Cloudflare или другой CDN, можно легко упустить ситуацию, когда на origin всё ок, а на edge уже нет. Поэтому мониторинг SSL — это не «дополнительная фишка», а часть нормальной доработки сайта и базовой эксплуатационной дисциплины.

Я обычно объясняю клиентам так: uptime-мониторинг показывает, что сайт жив, а SSL-мониторинг показывает, что он жив именно по HTTPS и без сюрпризов. Это разные вещи. У одного клиента на Laravel 11 с PHP 8.3 uptime был зелёный, а сертификат на поддомене api.example.ru протух. Внешне сайт работал, но интеграция с CRM и мобильным приложением падала по TLS. Пользователи этого не видели, а бизнес — очень даже.

Что контролировать в SSL-мониторинге

Я обычно разделяю SSL-мониторинг на несколько уровней. Первый — самый очевидный: срок действия сертификата. Второй — технический: корректность цепочки, домена, SAN, промежуточных сертификатов. Третий — эксплуатационный: что происходит при автопродлении, не падает ли nginx при reload, не ломается ли Apache после обновления, не конфликтует ли cron с certbot, не уезжает ли wildcard на другой хост.

Если вы используете Let’s Encrypt, самый частый сценарий — автопродление вроде бы настроено, но реально отрабатывает не всегда. Причины банальные: закрыт 80 порт, сломан DNS challenge, поменялся маршрут в Nginx, истёк API-токен у DNS-провайдера, криво работает контейнер с certbot. Поэтому мониторить надо не только наличие файла сертификата на сервере, но и сам процесс обновления. Это особенно актуально на VPS с Ubuntu 22.04/24.04, Debian 12, nginx 1.24+ и PHP 8.2/8.3.

Ещё одна важная вещь — уведомления. Их нужно делать не только на почту. Почта теряется, фильтруется, попадает в спам и просто игнорируется. Гораздо надёжнее дублировать: email + Telegram + Slack или хотя бы email + Telegram. У меня на практике Telegram почти всегда выигрывает, потому что сообщение видят сразу. А когда речь идёт о сертификате, у вас может быть всего 7–14 дней на реакцию, и тянуть до последнего нельзя.

• Срок действия сертификата: 30, 14, 7, 3 и 1 день до окончания.
• Корректность цепочки доверия и intermediate CA.
• Работа HTTP→HTTPS редиректа без петли.
• Состояние wildcard, SAN и поддоменов.
• Факт автопродления, а не только наличие cron-задачи.
• Ошибки reload/restart веб-сервера после обновления.

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

Какие варианты мониторинга есть в 2026 году

На деле вариантов несколько, и все они рабочие. Самый простой путь — использовать внешний сервис, который сам проверяет срок сертификата и шлёт уведомления. Второй путь — собственный скрипт на PHP или bash, который запускается по cron и присылает алерт в Telegram/Slack. Третий — комбинированный: внешний сервис следит за доступностью и SSL, а внутри сервера крутится локальная проверка автопродления.

Если у вас Bitrix на PHP 8.1 и MySQL 8.0, я бы не городил сложную кастомную систему без необходимости. Для большинства проектов достаточно UptimeRobot, Cronitor, Better Stack, Pingdom или StatusCake — у них в 2026 году SSL-чекинг уже вполне зрелый. Но если проект критичный, а доменов много, тогда я бы добавил собственную проверку через cron и уведомление в Telegram. Это уже не роскошь, а здравый смысл.

У WordPress-проектов часто пытаются решить всё плагином. И вот тут я бы сказал прямо: для SSL-мониторинга это плохая идея. Плагин внутри сайта не должен быть единственной точкой контроля. Если сайт лег, плагин не отправит уведомление, потому что сам сайт уже недоступен. Лучше вынести мониторинг наружу. А внутрь оставить только локальные проверки, если они реально нужны.

Если у проекта много поддоменов, например shop.example.ru, api.example.ru, crm.example.ru и dev.example.ru, я бы рекомендовал вести таблицу всех доменов и сроков отдельно. На крупных проектах это можно делать в Google Sheets, Notion или в простой таблице MySQL. Кстати, если у вас уже настроены собственные cron jobs, посмотрите мой материал про cron jobs — там хорошо видно, как это связать в одну систему.

Настройка через внешние сервисы и уведомления

Я обычно начинаю именно с внешнего сервиса. Это быстро, надёжно и не требует писать код. Самый популярный сценарий — добавить HTTPS endpoint, указать домен, выбрать срок предупреждения и подключить Telegram-бота или email. В 2026 году у большинства сервисов есть и Webhook-интеграции, и API, и мультиканальные оповещения. Это удобно, если у вас команда, где один человек отвечает за сервер, второй — за контент, третий — за интеграции.

На практике я чаще всего настраиваю уведомления в Telegram. Почта остаётся как backup-канал. И да, это в разы надёжнее, чем надеяться на одно письмо в inbox. Особенно если у клиента корпоративная почта на домене, а фильтр спама настроен слишком агрессивно. Про настройку почты с домена у меня есть отдельный материал — настройка почты для сайта. Очень советую его посмотреть, если уведомления планируются именно через SMTP.

Что важно при настройке сервиса:

• ставьте несколько порогов уведомления: 30/14/7/3 дня;
• дублируйте каналы: Telegram + email;
• включайте тестовое сообщение после добавления домена;
• проверяйте, видит ли сервис именно тот сертификат, который отдается пользователю;
• для CDN и reverse proxy проверяйте origin и внешний endpoint отдельно.

У одного клиента был кейс с Cloudflare и origin-сертификатом на отдельном IP. Внешний SSL выглядел идеально, а на origin стоял почти просроченный самоподписанный сертификат. Через месяц они меняли провайдера CDN, и весь сайт встал. Вот почему я всегда советую мониторить не только наружный HTTPS, но и то, что происходит внутри инфраструктуры. Иначе при миграции вы получаете сюрприз. Если у вас намечается смена площадки, пригодится статья про миграцию сайта на новый хостинг.

Мониторинг через PHP и cron: рабочий вариант для своих серверов

Если нужен полный контроль, я делаю простой PHP-скрипт, который проверяет дату окончания сертификата, сравнивает её с порогом и шлёт уведомление в Telegram. Это удобно для сайтов на Laravel, Bitrix и даже WordPress, если нужен свой внутренний контроль. Скрипт можно запускать по cron каждый день в 9:00 и, при необходимости, ещё и ночью. На VPS это почти ничего не стоит по ресурсам.

Ниже пример, который я не раз использовал на Ubuntu 24.04 с PHP 8.2 и 8.3. Он не идеальный, но рабочий. Для продакшена я обычно добавляю логирование, антидублирование уведомлений и запись в MySQL, чтобы не спамить команду одним и тем же алертом каждый день.

<?php
$host = 'example.com';
$port = 443;
$daysWarning = [30, 14, 7, 3, 1];
$telegramToken = '123456:ABCDEF';
$telegramChatId = '123456789';

$context = stream_context_create([
    'ssl' => [
        'capture_peer_cert' => true,
        'verify_peer' => false,
        'verify_peer_name' => false,
    ],
]);

$client = @stream_socket_client(
    "ssl://{$host}:{$port}",
    $errno,
    $errstr,
    30,
    STREAM_CLIENT_CONNECT,
    $context
);

if (!$client) {
    sendTelegram("SSL check failed for {$host}: {$errstr} ({$errno})");
    exit(1);
}

$cont = stream_context_get_params($client);
$cert = openssl_x509_parse($cont['options']['ssl']['peer_certificate']);

$validTo = $cert['validTo_time_t'];
$daysLeft = (int) floor(($validTo - time()) / 86400);

if (in_array($daysLeft, $daysWarning, true) || $daysLeft < 0) {
    $subject = $cert['name'] ?? $host;
    sendTelegram("SSL alert for {$subject}: {$daysLeft} days left");
}

function sendTelegram(string $message): void
{
    global $telegramToken, $telegramChatId;
    $url = "https://api.telegram.org/bot{$telegramToken}/sendMessage";
    $data = [
        'chat_id' => $telegramChatId,
        'text' => $message,
    ];

    $options = [
        'http' => [
            'header'  => "Content-type: application/x-www-form-urlencoded\r\n",
            'method'  => 'POST',
            'content' => http_build_query($data),
            'timeout' => 15,
        ]
    ];

    @file_get_contents($url, false, stream_context_create($options));
}

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

# /etc/cron.d/ssl-monitor
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin

0 9 * * * www-data /usr/bin/php /var/www/monitor/ssl-check.php >> /var/log/ssl-monitor.log 2>&1

Если вам нужна не только проверка сертификата, но и контроль автопродления, я бы добавил ещё одну задачу, которая проверяет статус certbot или acme.sh. Потому что бывает так: сертификат ещё действует, но продление уже сломано. Это как ездить на машине, у которой бензин пока есть, но датчик топлива уже умер. Формально всё ок, а по факту до первой остановки.

Настройка на nginx, Apache и .htaccess

На серверном уровне мониторинг SSL часто начинается не с внешнего сервиса, а с правильной конфигурации. У меня был случай, когда сертификат Let’s Encrypt обновлялся вовремя, но nginx не перечитывал новый файл после reload из-за ошибки в пути к fullchain.pem. Сертификат на диске был новый, а пользователям отдавался старый. Ситуация неприятная. И если бы не внешний мониторинг, это вылезло бы только после жалобы клиента.

Для nginx я обычно рекомендую отдельный location для health-check и корректную настройку HTTP→HTTPS. А если у вас ещё и HSTS, то тем более. Вот пример базовой конфигурации:

server {
    listen 80;
    server_name example.com www.example.com;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    location /healthz {
        access_log off;
        return 200 "ok\n";
        add_header Content-Type text/plain;
    }

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
    }
}

Для Apache логика похожая. Если у вас старый хостинг или Bitrix-проект на shared-среде, иногда приходится работать именно с .htaccess. Это не лучший вариант, но на практике до сих пор встречается часто. Главное — не допустить петель редиректа и не сломать SSL-проверку. Про это у меня есть отдельный разбор: переадресация с HTTP на HTTPS и WWW, а также материал про HTTPS редиректы и HSTS.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Если вы используете Bitrix, я бы ещё проверил, не мешает ли кеширование или прокси правильной отдаче сертификата на уровне фронта. Для таких проектов часто полезно держать под рукой настройку кеширования в Битрикс и материал про обратный прокси Nginx. Там часто и кроется проблема.

Уведомления: Telegram, почта, Slack и резервные каналы

Я почти всегда делаю несколько каналов оповещения. Один канал — это риск. Два канала — уже нормально. Три — хорошо. Например, основной алерт в Telegram, резервный на почту и ещё один в Slack для команды разработки. Если у вас есть дежурный админ или подрядчик, можно подключить и SMS, но это уже обычно лишнее, если не банк и не высоконагруженный сервис.

Важно не просто отправить уведомление, а отправить его так, чтобы оно было понятным. Не «SSL error», а «Сертификат example.com истекает через 7 дней, автопродление не подтверждено, проверь cron и certbot». Чем конкретнее сообщение, тем меньше лишних вопросов. Это экономит время. А на больших проектах время — это деньги, без всякой романтики.

Если уведомления идут через SMTP, проверяйте SPF, DKIM и DMARC. Иначе письмо может улетать в спам или блокироваться вовсе. У меня был клиент, который настраивал алерты через корпоративную почту, но письма уходили в quarantine. Мы потом отдельно правили DNS и почтовую политику. Кстати, если тема вам близка, посмотрите статью про DMARC, DKIM и SPF. Это очень помогает не только в SSL-мониторинге, но и вообще в доставке почты.

Типовые ошибки при мониторинге SSL

Самая частая ошибка — мониторить только дату окончания сертификата. Это слишком узко. Сертификат может быть ещё валидным, но сайт уже отдаёт неправильную цепочку, старый intermediate или не тот домен. Ещё одна ошибка — проверять только главную доменную зону и забывать про поддомены. Потом у вас внезапно ломается api.example.com, а все уверены, что «SSL же работает».

Второй класс ошибок — отсутствие теста уведомлений. Люди настраивают алерт, но ни разу не проверяют, доходит ли он. Я всегда делаю тестовую отправку сразу после конфигурации. И желательно на тот же канал, куда пойдут боевые уведомления. Иначе можно годами жить в иллюзии. А потом сертификат закончится, и никто ничего не узнает. Это, мягко говоря, не то, что нужно.

Третий тип проблем — автопродление без контроля результата. Certbot может завершиться с ошибкой, acme.sh — не обновить DNS challenge, а cron — вообще не запускаться из-за банального PATH. Поэтому я рекомендую проверять:

• код выхода задачи;
• изменился ли файл сертификата;
• прошёл ли reload веб-сервера;
• видит ли внешний мониторинг новый срок;
• не упал ли сайт после обновления.

Если после всей этой истории у вас ещё не настроены бэкапы, я бы не откладывал. SSL-мониторинг — это хорошо, но он не спасает от кривого обновления или ошибки администратора. Для общей безопасности я бы параллельно держал актуальный бэкап сайта и нормальный план отката. На практике это сильно снижает уровень паники.

Комплексный подход: SSL, uptime, логи и обслуживание

На самых нормальных проектах мониторинг SSL не живёт отдельно. Он связан с uptime, логами, бэкапами, безопасностью и обновлениями. И это правильная схема. Если вы отдельно смотрите сертификат, отдельно — доступность, отдельно — ошибки nginx, а отдельно — cron, вы тратите слишком много внимания. Гораздо лучше собрать всё в одну систему наблюдения.

Я обычно выстраиваю такую цепочку: сначала общий мониторинг сайта, потом SSL, потом логи, потом алерты по почте и Telegram. Для крупных сайтов добавляю ещё контроль по доменам, поддоменам и staging. Это особенно полезно на проектах, где есть отдельные окружения под тестирование и предпродакшн. И да, если у вас есть staging, он тоже должен быть под мониторингом. Иначе там тихо сломается сертификат, а вы узнаете об этом только в день релиза.

С точки зрения поддержки я бы вообще рекомендовал раз в месяц делать короткий технический аудит: что с сертификатами, что с редиректами, что с HSTS, не просрочился ли wildcard, не поменялись ли DNS-записи, не упал ли webhook уведомлений. Это легко встроить в настройку силами специалиста или в договор на поддержку WordPress и поддержку Битрикс. И, честно говоря, именно такой подход обычно экономит больше денег, чем попытка «сделать всё своими силами и забыть».

Если хотите оценить, во сколько обойдётся такая доработка на вашем проекте, можно сразу заглянуть в калькулятор стоимости сайта. Я обычно советую не экономить на мониторинге, потому что одна просрочка SSL на коммерческом проекте легко перекрывает стоимость нормальной настройки на месяцы вперёд. И если нужно не просто «поставить галочку», а реально сделать надёжно, тогда уже нужна полноценная доработать под задачу с учётом инфраструктуры, CMS и канала уведомлений.

На деле всё сводится к простой мысли: сертификат — это не файл на сервере, а часть живой системы. Система должна не только автоматически обновлять SSL, но и сообщать вам, если что-то пошло не так. Именно тогда мониторинг начинает приносить пользу, а не висит для галочки. Я бы однозначно делал это для любого коммерческого сайта в 2026 году, от небольшого корпоративного проекта до интернет-магазина на Bitrix 24/7 с PHP 8.3 и MySQL 8.0.