Раньше сертификат ставили раз в год, записывали дату в календарь и забывали. Теперь сроки жизни сертификатов сокращаются, и та же самая мина под приёмом платежей начинает срабатывать заметно чаще. Разбираем, почему стратегия «продлим, когда упадёт» стала дорогой и что настроить, чтобы сайт не ложился в субботу ночью.
Сценарий повторяется с завидной регулярностью и почти не меняется от компании к компании. Интернет-магазин работает год как часы: сервер настроен, оплата проходит, техподдержка вроде бы не нужна. В пятницу вечером сайт открывается нормально. В субботу утром покупатель нажимает «Оплатить», браузер показывает красный экран с предупреждением о небезопасном соединении, и человек просто уходит. Никто из ушедших не звонит и не пишет: зачем, если сайт «сломался», а рядом есть конкуренты с тем же товаром. Чем выше трафик, тем больше таких людей набирается за выходные.
В понедельник собственник открывает отчёт по продажам, видит провал и начинает искать виноватого. Виноватых нет. У сертификата закончился срок действия ночью в выходные, и об этом никто не узнал, потому что узнавать было некому и нечем.
Раньше с этим можно было жить. Сертификат выпускался на год, дата продления записывалась в календарь, и раз в двенадцать месяцев кто-то вспоминал и обновлял. Ошибка стоила денег, но случалась редко. Сейчас правила меняются, и та же самая схема начинает подводить заметно чаще.
Если сертификат уже истёк и платежи стоят прямо сейчас, не тратьте время на теорию: откройте план действий на первый час и параллельно напишите нам — контакты в конце статьи. Остальное можно спокойно читать, когда приём оплат восстановлен.
Индустрия движется в сторону коротких сертификатов, и это уже не прогноз, а зафиксированное направление. Центры сертификации и производители браузеров согласовали поэтапное сокращение максимального срока действия публичных TLS-сертификатов: сначала он уменьшается умеренно, затем существенно, а в перспективе нескольких лет речь идёт о сроках порядка недель вместо привычного года. Конкретные пороги и даты этапов стоит сверять по актуальным документам отраслевых объединений — они уточняются и переносятся. Но само направление сомнений не вызывает: сертификаты будут жить всё меньше, и обратного хода не предвидится.
Логика у этого решения здравая. Чем короче срок, тем меньше окно, в котором украденный ключ можно использовать, и тем быстрее вымываются из оборота ошибочно выпущенные сертификаты. Отзыв сертификатов на практике работает плохо: браузеры далеко не всегда проверяют списки отзыва, так что короткий срок жизни оказывается надёжнее любой процедуры отзыва. Для безопасности интернета это хорошо. Для владельца сайта, который привык обновлять сертификат вручную раз в год, это означает другое: операцию, которую делали однажды, придётся повторять несколько раз в год, а затем и чаще.
И вот здесь начинается арифметика риска. Одна ручная операция в год — это одна возможность забыть. Когда обновлений становится несколько за год, а доменов и поддоменов у компании больше одного, число таких возможностей растёт быстро. Дело не в дисциплине: человек уходит в отпуск, администратор увольняется, домен оформлен на бывшего подрядчика, а напоминание приходит на почтовый ящик, который никто не открывает. Чем больше повторов, тем выше вероятность, что однажды цепочка порвётся — и, скорее всего, в самый неудобный момент.
Ключевая мысль: короткие сертификаты не делают ручное продление сложнее. Они делают его нежизнеспособным. Процесс, который приходится повторять по десятку адресов через короткие промежутки, разумно сделать автоматическим — других вариантов индустрия практически не оставляет.
Самое неприятное в истёкшем сертификате — это не сам факт, а то, как он ломает бизнес. Разберём по слоям.
Покупатель видит страшное предупреждение. Современный браузер не показывает мелкую надпись где-то в углу. Он закрывает страницу целиком и предлагает уйти. Пройти дальше формально можно, но для этого нужно нажать «Дополнительно» и осознанно согласиться на риск. Обычный человек этого не делает. Он закрывает вкладку и идёт к конкуренту, и вы даже не узнаете о его существовании.
Платёжный шлюз перестаёт отвечать. Тут ломается не витрина, а машинная часть: колбэки от банка, уведомления об оплате, обмен данными с эквайрингом. Причём сломаться может как ваш сертификат, так и доверие вашего сервера к сертификату банка. Об этом мы подробно писали в материале про ошибку проверки TLS-сертификата при оплате. Внешне сайт может открываться нормально, а деньги при этом не доходят.
Поисковики фиксируют недоступность. Если робот пришёл на сайт в неудачный момент, страницы могут временно просесть или выпасть из выдачи. Восстановление занимает не часы, а заметно больше времени.
Приложения и интеграции отваливаются молча. Мобильное приложение, обмен с 1С, выгрузка на маркетплейс, телефония — всё это ходит по HTTPS и всё это перестаёт работать без единого сообщения об ошибке в интерфейсе. Узнать о поломке можно с большим опозданием: например, от бухгалтера, которому не пришли документы.
А теперь сложите стоимость. Простой в выходные, потерянные заказы, время разработчика в авральном режиме, испорченное впечатление у тех, кто увидел красный экран. Против этого — стоимость нормальной настройки, которую делают один раз и потом только поддерживают.
| Параметр | Ручное продление | Автоматическое продление и мониторинг |
|---|---|---|
| Кто помнит о сроке | Конкретный человек и его календарь | Система, которая работает без выходных |
| Что происходит в отпуске админа | Всё держится на удаче | Ничего не меняется |
| Сколько операций в год при коротких сертификатах | Несколько на каждый домен, и дальше чаще | Ноль ручных действий |
| Когда узнаете о проблеме | Когда упадут платежи | Заранее, за недели до истечения срока |
| Стоимость ошибки | Простой, потерянные заказы, аврал | Плановая работа в рабочее время |
Для бизнеса в России задача усложняется вдвое. Мало держать в порядке обычный публичный сертификат: многие банки и платёжные сервисы работают через российские корневые центры, и на сервере должна быть корректно установлена соответствующая цепочка доверия. Мы разбирали выбор между вариантами в статье HARICA или Минцифры, порядок установки — в инструкции по установке сертификата Минцифры, а базовые вещи — в материале о том, что такое TLS-сертификат и зачем он нужен для приёма платежей.
Практический вывод простой: у вас на сервере живёт не один сертификат, а несколько сущностей с разными сроками, разными процедурами обновления и разными последствиями при истечении. Держать это в голове невозможно. Держать в таблице можно, но таблица не разбудит вас ночью и не остановит выкатку, которая затирает конфигурацию.
Прежде чем что-то автоматизировать, нужно понять, что вообще есть. Чаще всего обнаруживается больше, чем помнил собственник: основной домен, www, тестовый поддомен, поддомен для API, отдельный сертификат на почтовый сервер, старый лендинг с прошлой рекламной кампании, о котором забыли, но он открывается и индексируется. Каждый из них — потенциальная точка отказа. Как посмотреть текущее состояние самому, мы описали в материале как проверить TLS-сертификаты на сервере.
Для большинства публичных доменов задача решается сертификатами с автоматическим обновлением: клиент на сервере сам обращается к центру сертификации, подтверждает владение доменом, получает новый сертификат и перезапускает веб-сервер. Настраивается один раз, дальше работает само. Важная деталь: автопродление нужно проверять в режиме пробного запуска и убеждаться, что после обновления сервис действительно перечитал новый файл. Частый сценарий, с которым мы сталкиваемся, выглядит так: сертификат обновился, а веб-сервер продолжал отдавать старый, потому что его никто не перезагрузил.
Автоматика тоже ломается. Меняется DNS, истекает домен, обновляется операционная система и ломает клиент, центр сертификации меняет протокол. Поэтому поверх автоматики нужен внешний мониторинг: сервис снаружи регулярно проверяет каждый ваш адрес и предупреждает, если до истечения осталось меньше двух-трёх недель или если цепочка отдаётся неполной. Уведомление должно приходить туда, где его увидят, — в рабочий мессенджер или звонком, а не на почтовый ящик, куда падает реклама.
Отдельно стоит проверять не только сам сертификат, но и промежуточные звенья цепочки. Классическая ловушка: в браузере на компьютере всё зелёное, а мобильное приложение и платёжный шлюз ругаются, потому что сервер отдаёт сертификат без промежуточного звена. Десктопный браузер достраивает цепочку сам, а строгий клиент этого не делает и просто разрывает соединение.
Автопродление настроили и забыли проверить. Установленный клиент не равен работающему процессу. Стоит хотя бы раз в квартал смотреть на дату выпуска действующего сертификата: если он обновлялся без вашего участия, механизм жив. Если дата давняя, значит, автоматика тихо остановилась и об этом никто не узнал.
Сертификат живёт в одном месте, а сервисов несколько. Веб-сервер, почтовый сервер, брокер сообщений, панель администратора на отдельном порту — каждый может держать собственную копию файла. Обновление одной копии не обновляет остальные, и проблема всплывает там, где её не ждут.
Выкатка затирает конфигурацию. Если деплой разворачивает конфиги из репозитория, он может перезаписать пути к свежим сертификатам старыми значениями. Такая поломка особенно неприятна тем, что происходит в момент релиза, когда внимание команды занято совсем другим.
Не проходит проверка владения доменом. Закрытый по IP тестовый контур, редирект на другой домен, изменившиеся DNS-записи — любая из этих мелочей ломает подтверждение, а значит, и обновление. Ошибка при этом остаётся в логах, куда никто не смотрит.
Никто не отвечает за процесс. Распространённая ситуация: сертификатами занимается тот, у кого есть доступ, а не тот, чья это зона ответственности. Как только человек меняет работу, знание уходит вместе с ним. Поэтому в нормальной схеме фиксируется не только настройка, но и то, кому приходят уведомления и что он делает по такому уведомлению. Смежные причины простоев мы разбирали в материале о том, почему перестал работать приём платежей на сайте.
Честно: далеко не всем. Если ваш сайт живёт на конструкторе или на массовом хостинге, где сертификатом управляет сама платформа, ничего делать не надо — там автопродление уже встроено, и вмешательство скорее навредит. Если у вас сайт-визитка без форм и оплат на одном домене, риск ограничивается неприятным предупреждением в браузере: обидно, но не критично, и можно обойтись бесплатным внешним мониторингом. Если в штате есть системный администратор, у которого автопродление настроено и проверено, тем более не нужно — попросите его показать логи последних обновлений и дату выпуска текущего сертификата.
Задача становится реальной, когда совпадает несколько условий: собственный сервер или VPS, приём онлайн-платежей, несколько доменов и поддоменов, интеграции с банком, 1С или мобильным приложением, российские корневые сертификаты в контуре. При таком наборе вероятность сбоя заметно возрастает: ручная схема держится на памяти конкретных людей, а поводов ошибиться становится всё больше.
Установка и настройка TLS-сертификатов стоит 40 000 ₽, срок работ 1–2 дня. В эту работу входит:
Если хочется, чтобы за состоянием сервера следили постоянно, а не разово, есть техническое сопровождение и настройка серверов от 15 000 ₽ в месяц: мониторинг доступности, обновления, резервные копии и те же сертификаты под присмотром.
Написать нам можно в WhatsApp или по телефону , в Telegram @nuclearlove, на почту antonezi2011@gmail.com. Аварии с сертификатами разбираем в приоритетном порядке, обычно в течение дня. А если сейчас всё работает — это лучший момент, чтобы посмотреть, когда истекает текущий сертификат и кто узнает об этом первым.
Индустрия действительно движется в эту сторону: центры сертификации и производители браузеров согласовали поэтапное сокращение максимального срока действия публичных сертификатов — сначала умеренное, затем более существенное. Конкретные пороги и даты этапов стоит сверять по актуальным отраслевым документам, они уточняются. Но планировать разумно исходя из того, что ручное продление раз в год как схема уходит в прошлое, и к коротким срокам лучше подготовиться заранее, а не в момент, когда платежи уже встали.
Оно закрывает основную часть, но не всю. Во-первых, автоматика сама ломается: меняется DNS, обновление системы ломает клиент, центр сертификации меняет протокол. Во-вторых, обновлённый файл нужно ещё подхватить — веб-сервер должен перечитать конфигурацию, иначе он продолжит отдавать старый сертификат. В-третьих, российские корневые сертификаты для работы с банками ставятся отдельно и по своей процедуре. Поэтому поверх автопродления стоит держать внешний мониторинг.
Три проверки. Первая: запустите обновление в тестовом режиме и убедитесь, что оно проходит без ошибок. Вторая: посмотрите дату выпуска текущего сертификата — если он выпущен недавно и без вашего участия, механизм жив. Третья, самая важная: проверьте сайт снаружи, а не на сервере, и убедитесь, что отдаётся именно новый сертификат с полной цепочкой. Дополнительно настройте внешнее уведомление за две-три недели до срока — оно поймает случай, когда автоматика тихо перестала работать.