Короткий ответ
Инвентаризация SSL-сертификатов — это список всех адресов проекта, где браузер, приложение, CRM, платежный модуль или робот поисковой системы подключается по HTTPS. В него входят не только главный домен, но и www, поддомены, API, личный кабинет, админка, тестовые витрины, страницы оплаты, вебхуки и служебные панели.
Если контролировать только главную страницу, можно пропустить сертификат, который истекает на отдельном узле. Для посетителя это выглядит как ошибка безопасности, неработающая форма, пустой виджет, сбой оплаты или недоступный личный кабинет. Поэтому проверку SSL лучше начинать не с одного домена, а с карты всех HTTPS-точек.
Тема стала особенно практичной после перехода отрасли к более коротким срокам публичных TLS-сертификатов. В базовых требованиях CA/Browser Forum указано, что с 15 марта 2026 года максимальный срок нового публичного TLS-сертификата составляет 200 дней, а дальше предусмотрено сокращение до 100 дней в 2027 году и до 47 дней в 2029 году: https://cabforum.org/working-groups/server/baseline-requirements/requirements/. Чем чаще продление, тем важнее знать, где именно у проекта есть сертификаты.
Почему забытые SSL-сертификаты опасны
SSL-сбой часто выглядит не как классическое падение сайта. Сервер может отвечать, база данных может работать, а мониторинг главной страницы может показывать нормальный статус. Но пользователь открывает нужный раздел и видит предупреждение браузера, потому что сертификат истек, выпущен не на тот домен или отдается не с той цепочкой.
Для бизнеса риск в том, что ломается не весь сайт сразу, а конкретный путь клиента. Например, каталог открывается, но форма заявки грузит скрипт с поддомена api.example.ru, где сертификат уже недействителен. Или посетитель доходит до оплаты, а платежный виджет обращается к старому поддомену, который никто давно не проверял. В отчетах это может выглядеть как падение конверсии без очевидной причины.
Есть и технический риск. Администратор может продлить сертификат для основного домена, но забыть про отдельный сервер с панелью управления, старый поддомен для вебхуков, адрес staging-среды или CDN-зону. Чем больше подрядчиков, интеграций и исторических настроек, тем выше шанс, что часть HTTPS-точек живет отдельно от основного процесса обслуживания.
Что включить в карту HTTPS-точек
Начните с адресов, которые видит клиент. Обычно это главный домен, вариант с www, мобильная версия, личный кабинет, корзина, оформление заказа, страница оплаты, форма заявки и разделы, на которые ведет реклама. Если один из этих адресов отдаст ошибку сертификата, проблема быстро станет пользовательской.
Затем добавьте технические адреса. Сюда относятся API, адреса для вебхуков, CDN-поддомены, панели CMS, административные интерфейсы, почтовые формы, файлы для интеграций, отдельные лендинги, промо-поддомены и старые домены, которые продолжают перенаправлять пользователей. Важно записывать не только доменное имя, но и назначение адреса: так проще понять, кто отвечает за исправление.
Отдельно проверьте внешние сервисы, которые подключены к сайту через ваш домен. Это могут быть конструктор посадочных страниц, облачная форма, helpdesk, виджет записи, хранилище файлов, CDN или платежный сценарий. Владелец сайта часто воспринимает их как часть проекта, хотя сертификат и DNS могут обслуживаться в другой панели.
Пример карты
Простая таблица может выглядеть так:
example.ru— основной сайт, проверяет хостинг;www.example.ru— публичный вариант домена, должен открываться так же, как основной;api.example.ru— заявки, формы и интеграции;lk.example.ru— личный кабинет клиентов;pay.example.ru— платежный сценарий или редирект на оплату;admin.example.ru— служебная панель, доступна только команде;promo.example.ru— старый лендинг, на который еще могут вести ссылки.
Даже если часть адресов закрыта авторизацией, сам TLS-ответ на 443 порту должен быть корректным. Проверка сертификата происходит до входа в личный кабинет, поэтому ошибка HTTPS появится раньше, чем пользователь увидит форму логина.
Как найти поддомены и не пропустить старые адреса
Первый источник — DNS-зона. Посмотрите A, AAAA, CNAME и ALIAS-записи, которые ведут на сайт, CDN, облачные платформы и сторонние сервисы. Если запись существует, стоит понять, открывается ли она по HTTPS и нужна ли она сейчас.
Второй источник — настройки сайта и аналитики. Проверьте ссылки в меню, sitemap.xml, robots.txt, рекламные кабинеты, письма рассылок, шаблоны уведомлений, CRM, вебхуки и интеграции. Старый URL может не встречаться на главной странице, но продолжать использоваться в письмах или в автоматических сценариях.
Третий источник — история проекта. После переезда на другой хостинг, смены CMS, подключения CDN или запуска отдельного лендинга часто остаются временные поддомены. Их не обязательно сразу удалять, но нужно либо контролировать, либо осознанно выключить, чтобы они не создавали скрытую точку отказа.
Что проверить вручную
Для каждого адреса откройте HTTPS-версию в браузере и посмотрите, нет ли предупреждения безопасности. Затем проверьте, на какой домен выпущен сертификат, покрывает ли он текущий поддомен, не истек ли срок действия и не отдается ли старый сертификат после продления.
Если есть доступ к командной строке, полезно проверять сертификат напрямую снаружи, а не только из панели хостинга. Важно смотреть именно тот адрес, который открывают пользователи. Разные виртуальные хосты на одном сервере могут отдавать разные сертификаты, поэтому проверка IP-адреса не заменяет проверку домена.
Частые ошибки при учете SSL
Первая ошибка — считать, что wildcard-сертификат решает все. Он может покрывать часть поддоменов, но не всегда закрывает вложенные уровни, отдельные домены, старые зоны и адреса, которые обслуживаются сторонней платформой. Кроме того, даже корректно выпущенный сертификат должен быть установлен на нужном сервере.
Вторая ошибка — проверять только дату окончания. Сертификат может быть еще действующим, но браузер покажет проблему, если домен не совпадает, цепочка неполная, сервер отдает не тот сертификат или часть пользователей попадает на старый балансировщик. Поэтому в чеклисте нужен не только срок, но и результат реального HTTPS-подключения.
Третья ошибка — хранить список в голове у одного специалиста. Если человек уходит в отпуск или подрядчик меняется, команда может не знать, что сертификат для отдельного поддомена продлевается вручную. Лучше вести простой реестр: адрес, назначение, ответственный, где выпускается сертификат, как продлевается и чем проверяется.
Как настроить регулярный контроль
После инвентаризации разделите адреса по важности. Критичные точки — главный сайт, формы заявок, личный кабинет, API и оплата — нужно проверять автоматически. Менее важные адреса можно проверять реже, но они тоже должны быть в списке, если доступны пользователям или поисковым роботам.
Для каждого критичного адреса настройте проверку доступности по HTTPS. Хороший контроль должен замечать не только полный отказ сайта, но и SSL-ошибку, неправильный код ответа, долгий ответ сервера или ситуацию, когда страница открылась, но в ней нет ожидаемого текста. Это помогает отличить нормальную работу от скрытого сбоя.
В Web-Puls можно добавить важные адреса сайта в мониторинг, чтобы регулярно проверять доступность и быстрее узнать, если HTTPS перестал работать корректно. Для SSL-темы это особенно полезно: владелец видит не календарное напоминание, а реальную проверку того, что пользовательский адрес открывается.
Когда стоит обратиться за помощью
Если на проекте много поддоменов, несколько хостингов, CDN, старая DNS-зона и внешние интеграции, инвентаризация может быстро стать технической задачей. В такой ситуации важно не менять записи наугад: ошибка в DNS или конфигурации HTTPS может затронуть работающие разделы.
При сложных сбоях с SSL, DNS, хостингом или сервером можно обратиться за профессиональной поддержкой через форму https://web-puls.ru/support/ или использовать контактную информацию на https://web-puls.ru/contacts/. В заявке лучше сразу указать домен, проблемный поддомен, текст ошибки браузера и что уже проверяли.
Вывод
Инвентаризация SSL-сертификатов нужна не только крупным компаниям. Даже у небольшого сайта со временем появляются поддомены, API, старые лендинги и внешние сервисы. Если они не попали в контроль, SSL-ошибка может остановить заявку, оплату или вход в личный кабинет, хотя главная страница будет выглядеть рабочей.
Практический порядок простой: собрать все HTTPS-адреса, записать их назначение, проверить сертификат снаружи и настроить автоматический мониторинг для критичных точек. Так SSL перестает быть разовой настройкой и становится частью нормальной поддержки сайта.