Браузер еще недавно открывал сайт банка или крупной российской компании, а теперь показывает ERR_CERT_REVOKED и не дает пройти дальше. Перезагрузка страницы, очистка кэша, смена DNS и режим инкогнито не помогают. Такое поведение логично. Удостоверяющий центр досрочно отозвал TLS-сертификат, а браузер перестал считать сервер подлинным.
Пользователь не может восстановить отозванный сертификат. Исправить исходную проблему должен владелец сайта, установив новый сертификат на все серверы. Однако российская ситуация сложнее. После массовых отзывов зарубежных сертификатов часть компаний перешла на сертификаты Национального удостоверяющего центра Минцифры. В таком случае браузер может показать уже не ERR_CERT_REVOKED, а ERR_CERT_AUTHORITY_INVALID, SEC_ERROR_UNKNOWN_ISSUER или другое сообщение о неизвестном центре. Решения для двух ошибок различаются.
Что именно проверяет браузер
При подключении по HTTPS сервер отправляет браузеру TLS-сертификат. В сертификате указаны доменные имена, открытый ключ, издатель и срок действия. Браузер строит цепочку от сертификата сайта через промежуточные центры до корневого сертификата, которому доверяет операционная система или сам браузер.
Успешная проверка подтверждает три свойства соединения. Браузер подключился к владельцу нужного домена, трафик зашифрован, а переданные данные нельзя незаметно изменить по дороге. Значок защищенного соединения не доказывает порядочность владельца сайта. Мошенник тоже может получить обычный доменный сертификат для своего фишингового адреса.
Срок действия сертификата может еще не закончиться, но удостоверяющий центр вправе отозвать документ раньше. Среди стандартных причин встречаются утечка закрытого ключа, ошибочная выдача, нарушение правил центра, прекращение работы домена и компрометация удостоверяющего центра. В российском случае добавились санкционные и договорные ограничения.
Летом GlobalSign начал отзывать сертификаты российских организаций, попавших под ограничения. По опубликованным участниками рынка оценкам, первоначальный список мог затронуть 15–20 тысяч доменов второго уровня. Полного публичного реестра всех пострадавших ресурсов нет, поэтому цифру нельзя считать точным итогом. Позже появились новые волны отзыва, а компании стали переходить между международными центрами и российским НУЦ. Хронологию и масштаб событий подробно разбирал SecurityLab.
Отзыв сертификата не доказывает взлом сайта. GlobalSign мог прекратить доверие по юридическим причинам, даже если закрытый ключ не утекал и сервер не атаковали. Браузер при этом обязан относиться к сертификату как к недействительному. Пользователь не знает точную причину отзыва и не может безопасно решить, что предупреждение «наверняка формальное».
Браузеры узнают об отзыве разными способами. Chrome получает компактные списки CRLSet и блокирует включенные в них сертификаты. Chrome обычно не отправляет отдельный OCSP-запрос для каждого посещенного сайта. Firefox на настольных системах использует CRLite, локальную базу отозванных сертификатов, которая обновляется примерно дважды в сутки. Safari и Edge также учитывают собственные правила браузера и механизмы операционной системы.
Из-за различий один браузер может заблокировать сайт раньше другого. Работа страницы в соседнем браузере не доказывает, что сертификат действителен. Второй браузер мог еще не получить обновленный список, не включить конкретный отзыв в локальную базу или построить другую цепочку сертификатов.
Код ошибки помогает понять источник проблемы.
ERR_CERT_REVOKEDозначает, что браузер считает сертификат отозванным.ERR_CERT_AUTHORITY_INVALIDозначает, что браузер не доверяет издателю или не смог построить цепочку до доверенного корня.SEC_ERROR_REVOKED_CERTIFICATEсообщает об отзыве в Firefox.SEC_ERROR_UNKNOWN_ISSUERуказывает на неизвестный центр, неполную цепочку или локальный перехват HTTPS.ERR_CERT_DATE_INVALIDсвязан со сроком сертификата либо неверными датой и временем на устройстве.
После перехода сайта с отозванного сертификата GlobalSign на сертификат Минцифры ошибка ERR_CERT_REVOKED обычно должна исчезнуть. Иностранный браузер без российского корневого сертификата может заменить ее сообщением о неизвестном издателе. Новый код не означает, что замена не состоялась. Браузер просто не знает новый корень доверия.
Как проверить проблему без опасных обходов
Я начинаю с точного кода ошибки. Пользователи часто объединяют все предупреждения браузера под названием «ошибка сертификата», хотя причины и способы исправления заметно отличаются.
- Проверьте адрес сайта посимвольно. Используйте закладку, официальное приложение или адрес из подтвержденного канала организации.
- Откройте сведения о сертификате на странице предупреждения. Запишите издателя, доменные имена, срок действия и серийный номер.
- Проверьте сайт через мобильный интернет, предварительно отключив Wi-Fi. Затем повторите тест через домашнюю сеть.
- Сравните результат в другом обновленном браузере, но не воспринимайте успешное открытие как гарантию безопасности.
- Проверьте несколько несвязанных HTTPS-сайтов. Массовые ошибки на одном устройстве чаще указывают на антивирус, прокси, корпоративный фильтр или поврежденное хранилище сертификатов.
Смена сети помогает найти не только локальную неисправность. Крупные сайты работают через CDN, балансировщики и несколько центров обработки данных. Один узел может уже отдавать новый сертификат, а другой продолжать использовать отозванный. Отдельные конфигурации обслуживают IPv4 и IPv6, поэтому два подключения к одному домену иногда получают разные цепочки.
На Windows базовую диагностику можно провести встроенной версией curl.
curl.exe -Iv https://example.ru/Команда покажет, состоялось ли TLS-соединение и какую ошибку вернула системная библиотека Windows. Вместо example.ru нужно указать проверяемый домен.
OpenSSL позволяет посмотреть сертификат, цепочку и ответ OCSP Stapling, если сервер его отправляет.
openssl s_client -connect example.ru:443 -servername example.ru -showcerts -statusСтрока OCSP response: no response sent не означает, что сертификат действителен или отозван. Сервер мог просто не поддерживать OCSP Stapling. Обычный запуск openssl s_client также не проводит полноценную проверку по всем актуальным спискам отзыва.
Антивирус, корпоративный прокси или программа родительского контроля могут расшифровывать HTTPS и выпускать локальный сертификат для каждого посещаемого сайта. В окне сертификата тогда появится название антивируса, работодателя или неизвестной программы вместо публичного удостоверяющего центра. Когда одинаковая ошибка возникает на множестве крупных сайтов только на одном компьютере, такой сценарий вероятнее массового отзыва настоящих сертификатов.
Не отключайте антивирусную проверку HTTPS навсегда. Для разового теста можно временно приостановить соответствующий модуль, открыть один заведомо известный сайт и сразу вернуть настройку. Рабочий компьютер лучше передать системному администратору. Корпоративный сертификат мог быть установлен намеренно.
Материал предназначен для легальной диагностики собственных устройств, сайтов и серверов. Соблюдайте законодательство своей страны, особенно России. Не применяйте сетевые инструменты для несанкционированного доступа, перехвата чужого трафика, слежки, взлома или незаконного обхода ограничений.
Что делать обычному пользователю
При подтвержденном ERR_CERT_REVOKED я не советую искать кнопку обхода. Не вводите пароль, данные карты, код из СМС или резервную фразу. Владелец сайта должен заменить сертификат. Очистка истории, кэша, DNS и файлов cookie не меняет статус документа у удостоверяющего центра.
VPN также не «чинит» отозванный сертификат. Другая сеть может направить соединение на уже обновленный узел CDN, поэтому сайт иногда начинает работать. Такой результат говорит о неодинаковой конфигурации серверов, а не о восстановлении доверия к старому сертификату.
После перехода сайта на сертификат НУЦ Минцифры у пользователя появляется два практических варианта. Можно открыть ресурс в браузере, куда российские корневые сертификаты уже встроены, либо установить корневой и выпускающий сертификаты вручную. Файлы и инструкции следует брать только на официальной странице Минцифры.
Я предпочитаю отдельный браузер для банковских и государственных ресурсов вместо системной установки нового корня на основное устройство. Такой подход не делает российский сертификат автоматически вредоносным, но уменьшает область доверия и упрощает контроль.
Корневой сертификат разрешает удостоверяющему центру подтверждать сертификаты не только одного банка, но и любых доменов. Само добавление корня не открывает Минцифры, интернет-провайдеру или постороннему человеку доступ к переписке и паролям. Для перехвата потребуется одновременно направить трафик на чужой сервер и предъявить сертификат, который устройство примет как действительный. Однако установка любого нового корня расширяет круг организаций, которым устройство доверяет подтверждать сайты.
Нельзя скачивать сертификаты из Telegram, почтовых вложений, форумов и облачных папок. Поддельный корень способен дать злоумышленнику широкие возможности для подмены HTTPS при контроле сети или устройства. Даже правильное имя файла ничего не доказывает.
Мобильные платформы добавляют ограничения. На iPhone и iPad загрузки профиля недостаточно. Пользователь должен отдельно включить полное доверие корневому сертификату в настройках. На Android приложения, рассчитанные на Android 7 и новее, по умолчанию могут не доверять пользовательским корневым сертификатам. Поэтому сайт откроется в браузере, а банковское приложение продолжит выдавать сетевую ошибку.
Мобильное приложение также может использовать собственное хранилище или certificate pinning. Ручная установка корня тогда не поможет. Нужен новый выпуск приложения либо изменение серверной цепочки, предусмотренное разработчиком.
Не запускайте Chrome с параметром --ignore-certificate-errors, не отключайте проверку отзыва в системных настройках и не меняйте политики браузера по случайной инструкции. Такие действия убирают предупреждение, но одновременно позволяют принять действительно скомпрометированный сертификат.
Что проверить владельцу сайта
Администратору нужно выяснить, какой сертификат фактически получают пользователи, а не только какой файл лежит на основном веб-сервере. Проверка должна охватить CDN, WAF, балансировщики, резервные площадки, API, личные кабинеты, платежные страницы, IPv4 и IPv6.
Новый сертификат следует установить вместе с полной цепочкой промежуточных центров. Неполная цепочка способна вызвать ошибку неизвестного издателя, хотя сам конечный сертификат остается действительным. После замены нужно проверить все домены из SAN, а также старые адреса, редиректы и отдельные поддомены мобильного API.
Проверить конкретный сервер можно напрямую по IP, сохранив правильное имя в SNI.
openssl s_client -connect 203.0.113.10:443 -servername example.ruКоманду повторяют для каждого адреса из DNS-записей A и AAAA. Разные серийные номера сертификатов на узлах не всегда означают ошибку, но каждый сертификат должен быть действительным и подходить домену.
Если точная причина отзыва неизвестна или возможна утечка закрытого ключа, при выпуске нового сертификата нужно создать новую ключевую пару. Повторное использование предположительно скомпрометированного ключа лишает замену смысла.
Особое внимание требуется мобильным приложениям. Pinning старого конечного сертификата или сертификата прежнего центра сломает соединение после миграции. Привязка к публичному ключу может пережить обычное перевыпускание, если ключ сохранился, но сохранять старый ключ нельзя при подозрении на компрометацию. Надежная схема pinning предусматривает резервный ключ и обновление приложения до плановой ротации.
ERR_CERT_REVOKED не лечится пользовательским трюком. При настоящем отзыве нужно дождаться нового сертификата. При переходе на НУЦ следует проверить точный код ошибки и выбрать доверенный браузер либо официальную установку корня. Главные риски начинаются там, где пользователь игнорирует предупреждение, скачивает сертификат из случайного источника или отключает проверку TLS целиком.
