Отозванный SSL-сертификат может выглядеть действующим по дате, но браузер уже не доверяет ему и блокирует HTTPS-соединение. Владелец сайта видит ошибку ERR_CERT_REVOKED, посетители не могут открыть каталог, личный кабинет или форму оплаты, а обычная проверка срока действия не объясняет причину. Разберём, чем отзыв отличается от истечения сертификата, как подтвердить диагноз и безопасно вернуть сайт в работу.
Почему тема отзыва SSL-сертификатов стала актуальной
В июне 2026 года «Российская газета» и РБК сообщили о поэтапном отзыве части сертификатов GlobalSign у российских организаций. Это важный инфоповод, но не повод считать любой сбой HTTPS следствием одной кампании: сертификат могут отозвать и по другим причинам, а похожее предупреждение иногда возникает из-за неверной цепочки, имени домена или часов на устройстве.
Технически отзыв означает досрочное прекращение доверия к сертификату. В справке GlobalSign описаны два стандартных механизма распространения статуса: список отозванных сертификатов CRL и протокол OCSP. Поэтому дата «действителен до» в свойствах сертификата не доказывает, что с ним всё в порядке.
Что означает ERR_CERT_REVOKED
У каждого TLS-сертификата есть издатель, серийный номер, срок действия и статус. Удостоверяющий центр может пометить уже выданный сертификат как отозванный. После этого клиент, который получил достоверную информацию об отзыве, должен перестать считать сертификат надёжным.
Отзыв и окончание срока — не одно и то же
Истёкший сертификат перестаёт действовать после указанной даты. Отозванный теряет доверие раньше этой даты. Простое продление старого экземпляра проблему не решает: нужен новый сертификат с новым серийным номером и корректная установка на все точки, где завершается TLS.
Почему сертификат отзывают
Возможные причины включают компрометацию закрытого ключа, ошибочный выпуск, замену сертификата новым, прекращение его использования или требования политики удостоверяющего центра. Точную причину следует искать в уведомлении центра сертификации, личном кабинете поставщика или ответе технической поддержки. По одному сообщению браузера нельзя уверенно определить, почему произошёл отзыв.
Как убедиться, что проблема именно в сертификате
1. Зафиксируйте адрес и текст ошибки
Запишите полный URL, время проверки, браузер и сеть. Уточните, не открывается весь сайт или только отдельный адрес: например, www.example.ru работает, а checkout.example.ru выдаёт предупреждение. Это разные TLS-узлы, даже если внешне они относятся к одному проекту.
Не советуйте посетителям обходить предупреждение и вводить пароль или данные карты. Пока причина не установлена, такой обход стирает важную защитную границу.
2. Сравните результат из нескольких точек
Откройте адрес с другого устройства и через другую сеть, затем выполните внешнюю проверку SSL. Если ошибка появляется только на одном компьютере, проверьте системное время, обновления браузера, корпоративный прокси и защитное ПО. Если один и тот же статус виден из независимых сетей, вероятнее проблема на стороне сайта или его TLS-провайдера.
3. Посмотрите издателя и серийный номер
В окне сведений о сертификате сохраните:
- имя издателя;
- серийный номер;
- отпечаток;
- период действия;
- список доменных имён;
- состав цепочки до корневого центра.
4. Проверьте ответ сервера через OpenSSL
Для первичной диагностики можно запросить цепочку и OCSP stapling:
openssl s_client -connect example.ru:443 -servername example.ru -status </dev/null
Параметр servername обязателен для сайтов с SNI: без него сервер может показать сертификат другого виртуального хоста. Команда status просит сервер приложить OCSP-ответ. Если ответа нет, это ещё не доказывает, что сертификат отозван или действителен: сервер мог не настроить stapling. Для окончательной проверки сопоставьте серийный номер с данными OCSP или CRL конкретного удостоверяющего центра либо используйте его официальный инструмент.
5. Проверьте все внешние узлы
HTTPS может завершаться не на веб-сервере, а на CDN, балансировщике, reverse proxy или облачной панели. Отдельные сертификаты часто используются на API, панели администратора, платёжном поддомене и почтовом интерфейсе. Составьте список точек и проверьте каждую — успешное открытие главной страницы не подтверждает исправность остальных.
Как восстановить доступ к сайту
Шаг 1. Сохраните факты до изменений
Зафиксируйте проблемный сертификат, конфигурацию TLS и список затронутых доменов. При подозрении на утечку ключа ограничьте доступ к нему и следуйте процедуре реагирования вашей организации.
Шаг 2. Выпустите новый сертификат
Запросите перевыпуск у текущего поставщика. Если он больше не может обслуживать организацию или нужный тип сертификата, выберите другой удостоверяющий центр, которому доверяют браузеры и устройства вашей аудитории. Для выпуска потребуется подтвердить контроль над доменом; заранее проверьте DNS, доступность служебного HTTP-адреса или другой выбранный способ валидации.
Шаг 3. Установите сертификат вместе с цепочкой
Разместите новый сертификат и промежуточные сертификаты на каждой точке завершения TLS. Проверьте соответствие закрытого ключа, права доступа к файлам и синтаксис конфигурации, затем выполните безопасную перезагрузку сервиса. Если используется CDN или балансировщик, обновление только на origin-сервере не изменит сертификат, который видит посетитель.
Шаг 4. Проверьте результат снаружи
После установки убедитесь, что внешний сервер отдаёт новый серийный номер, имя домена совпадает, цепочка строится полностью, а браузер не показывает предупреждение. Проверьте каждый важный поддомен: старый сертификат не должен появляться на отдельном узле кластера.
Шаг 5. Проверьте бизнес-сценарии
Рабочий TLS на главной странице — только технический минимум. Откройте вход в личный кабинет, корзину, оплату, API и формы обратной связи. Отдельно проверьте API-домен мобильного приложения.
Практические примеры
Интернет-магазин заменил сертификат только на главном домене
Главная страница www.example.ru снова открылась, но оплата осталась недоступной. Проверка показала, что checkout.example.ru обслуживает отдельный балансировщик со старым отозванным сертификатом. Исправление — выпустить сертификат с нужным именем, установить его на платёжный узел и проверить сценарий заказа с внешней сети.
Wildcard-сертификат использовался на нескольких сервисах
Администратор обновил сертификат на сайте, но забыл API и панель управления. В результате пользователи видели рабочий каталог, а интеграции получали TLS-ошибку. Такой случай показывает, почему инвентаризация должна связывать сертификат не только с доменом, но и с конкретными серверами, прокси и ответственными сотрудниками.
CDN и origin показывали разные сертификаты
На origin уже находился новый сертификат, однако посетители продолжали получать ошибку. TLS завершался на CDN, где оставался старый экземпляр. После обновления сертификата на edge-уровне и внешней проверки проблема исчезла. Обратная ситуация тоже возможна: браузер видит корректный edge-сертификат, а CDN не может подключиться к origin из-за ошибки его TLS.
Как не узнать об отзыве от клиента
Обычная проверка даты окончания недостаточна. В регламент мониторинга стоит включить:
- строгую проверку TLS без режима «игнорировать ошибки сертификата»;
- контроль главного домена, API, оплаты и других критичных поддоменов;
- уведомления о недоступности и проблемах SSL;
- инвентаризацию издателей, серийных номеров и мест установки;
- ответственного и понятный порядок экстренного перевыпуска;
- проверку пользовательских сценариев после каждой замены.
Чтобы не открывать сайт вручную после каждого изменения, можно настроить регулярный мониторинг доступности и SSL в Web-Puls. Важно следить не только за главной страницей, но и за адресами, от которых зависят вход, заказы и интеграции.
Когда нужна профессиональная помощь
Если неизвестно, где завершается TLS, сертификат одновременно установлен на CDN и нескольких серверах или после замены сохраняется ошибка, полезно привлечь специалиста. Оставить описание ситуации и адрес сайта можно через форму профессиональной поддержки или выбрать удобный способ связи на странице контактов.
Вывод
ERR_CERT_REVOKED нельзя исправить очисткой браузера или ожиданием даты продления. Сначала подтвердите статус конкретного сертификата, затем выпустите новый экземпляр, установите полную цепочку на все TLS-узлы и проверьте реальные пользовательские сценарии снаружи. Инвентаризация и строгий автоматический мониторинг помогают обнаружить такой сбой раньше клиентов. Web-Puls можно использовать для регулярной проверки доступности и SSL на важных адресах.