Сертификаты — не просто техника, а бизнес-риск
издание habr-infosec пишет, что сбои из-за истечения TLS-сертификатов — не редкость, а системная проблема. Инциденты случаются даже у крупных сервисов, потому что управление цифровыми сертификатами остаётся ручным. Я считаю, что это не просто техническая оплошность, а признак устаревшего подхода к безопасности, который влияет на репутацию и работу бизнеса.
Сертификаты — не просто техника, а бизнес-риск
Что происходит, когда TLS-сертификат заканчивается? Сайт перестаёт быть доступным для пользователей. Браузеры блокируют подключение. Это не «временный сбой» — это прямое влияние на выручку. Особенно если это сайт с оплатой, регистрацией или доступом к данным. Мы в Cetera видим такие инциденты не раз. Их не отменить, только предотвратить.
Сертификат — это не просто файл. Это часть доверия. Когда он истек, пользователь видит предупреждение. Даже если он не понимает, что это за ошибка, он уходит. И не возвращается. Это не технический сбой — это потеря клиентов.
Я считаю, что устаревший подход к управлению сертификатами — это не ошибка, а системная слабость. Когда ручной контроль, Excel-таблицы и напоминания в календаре — основа управления, утечка неизбежна. А утечка — это не только сбой, но и репутационный урон.
Как работает жизненный цикл сертификата
TLS-сертификат — это цифровой документ, подтверждающий, что сайт принадлежит определённой организации. Он выдаётся доверенным центром и имеет срок действия — обычно от 90 до 365 дней. Потом его нужно обновить. Если не обновить — подключение блокируется.
Раньше это делали вручную. Специалисты вручную проверяли сроки, запускали запросы на выдачу, устанавливали новый сертификат. Это работало, пока проектов было мало. Но когда их становится десятки — ручной контроль становится невозможным.
Сейчас есть инструменты, которые автоматизируют этот процесс. Например, cert-manager в Kubernetes. Но как показывает практика, просто установить такой инструмент — не решение. Нужна интеграция с системами мониторинга, архивированием, аудитом. Иначе автоматизация не работает.
Что изменилось: от ручного контроля к системе
Раньше, когда сайтов было мало, и все они были на одном сервере, можно было вручную отслеживать сроки. Сейчас всё иначе. У компании может быть десяток доменов, сотни поддоменов, сервисов в облаке, микросервисов — и каждый нуждается в сертификате.
Раньше устаревание сертификата было редкостью. Сейчас — это системная угроза. Сбои из-за истечения сертификатов фиксируются в отчётах, упоминаются в новостях. Это не «случайность» — это следствие отсутствия автоматизации.
Сейчас рынок предлагает решения, которые не просто выдают сертификат, а управляют его жизненным циклом: от запроса до отзыва. Это не просто инструмент, а часть архитектуры. И такие решения уже не роскошь — они обязательны.
Кто в зоне риска — и как это узнать
Если у вас есть сайт с оплатой, личный кабинет, доступ к данным — сертификаты критичны. Если вы не контролируете сроки, не получаете уведомления, не видите, кто и когда обновил — вы в зоне риска.
Признаки: вы сталкиваетесь с «неожиданными» сбоями в часы пик, пользователи жалуются на «ошибку безопасности», вы получаете уведомления от провайдера, но не знаете, что делать. Это не «неполадка» — это сигнал.
Даже если сайт работает, это не значит, что всё в порядке. Устаревший процесс — это устаревший сайт. И он уже не даёт того, что дают другие: стабильность, доверие, автоматизацию.
Что делать — шаги в общем виде
Начинаем с аудита: выявляем все домены, поддомены, сервисы, которые используют TLS. Проверяем, где сертификаты управляются, и как. Это не про «настроил» — это про «кто отвечает», «как контролируется», «что происходит при истечении».
Затем — оценка рисков. Определяем, какие сервисы при сбое будут критичны. Ставим приоритеты. Не все сервисы требуют одинакового уровня автоматизации.
Далее — проектируем систему. Выбираем инструмент, который подходит по масштабу. Настройка интеграций с мониторингом, архивированием, системами управления доступом. Обязательно — тестирование в продакшене.
И наконец — внедрение. Не с «всё сразу», а поэтапно. Сначала — критичные сервисы. Потом — остальные. Контроль качества и обучение команды.
Что мы с этим делаем
Мы в Cetera такие системы проектируем и внедряем. Начинаем с аудита инфраструктуры: выявляем все точки, где нужен сертификат. Считаем нагрузку, определяем уязвимые места. В таких проектах сначала считаем нагрузку, потом — архитектуру.
Такие интеграции ставим на очередь обмена. Работаем с системами мониторинга, CI/CD, инфраструктурой. У нас нет субподрядчиков — всё делаем своим штатом. Поддерживаем и развиваем проекты на Cetera CMS, 1С-Битрикс, Laravel, Yii2, InSales, WordPress, Magento2 и других платформах.
Работаем с 2002 года, более 1000 проектов. Сайт устаревает не тогда, когда ломается, а когда перестаёт давать то, что уже дают другие. Свяжитесь с нами — разговор о задаче.
Это часть нашей работы — Поддержка и развитие. Поддерживаем сайты всех типов на CMS и фреймворках: Cetera CMS, Laravel, Yii2, InSales, «1С-Битрикс», Bitrix24, WordPress, WooCommerce, Ecwid, OpenCart, Drupal, Joomla, Magento2, Shopify и самописные системы на PHP и Python. Инфраструктура, развитие и продвижение включены. Поддержка и развитие
Автор: Святослав Семенов из Cetera Labs