NET::ERR_CERT_REVOKED: сертификат сайта отозван

NET::ERR_CERT_REVOKED значит, что сертификат сайта отозван: центр сертификации объявил его недействительным раньше срока, и браузер об этом узнал. Chrome показывает «Подключение не защищено» и код ошибки, а кнопки «Перейти на сайт» на этом экране нет. Мы выпустили свой отозванный сертификат, подняли сервер OCSP и список отзыва и проверили, когда Chromium 149 и Firefox 151 блокируют сайт, а когда пропускают.

Срок и издателя сертификата своего сайта можно посмотреть проверкой доступности: наш сервер запрашивает страницу и показывает код ответа, время отклика и данные SSL-сертификата.

Что означает ошибка

Сертификат действует до даты, записанной в нём самом. Но центр сертификации может отозвать его и раньше: внести серийный номер в список отзыва (CRL) или отвечать «отозван» на запросы по протоколу OCSP. После этого сертификат формально ещё не истёк, но доверять ему уже нельзя.

В исходниках Chromium, в файле net_error_list.h, у ошибки код −206 и пояснение: сервер ответил сертификатом, который был отозван; эту ошибку можно было бы игнорировать, но, вероятно, делать этого не стоит. Рядом стоят две родственные ошибки: −205 CERT_UNABLE_TO_CHECK_REVOCATION (проверить отзыв не удалось) и −204 CERT_NO_REVOCATION_MECHANISM (в сертификате нет адреса для проверки). Обе появляются только там, где проверку отзыва сделали обязательной, например политикой в организации.

Полный текст в Chromium 149 на русском, после нажатия «Дополнительные настройки»:

Сертификат веб-сайта 127.0.0.1 отозван. Открыть сайт в настоящее время нельзя. Сбой мог быть вызван сетевой ошибкой или действиями злоумышленников. Скорее всего, сайт заработает через некоторое время.

Заглушка та же, что и при других ошибках сертификата, но вместо «Вернуться к безопасной странице» на ней кнопка «Перезагрузить», а ссылки «Перейти на сайт (небезопасно)» нет вовсе.

Как браузер узнаёт об отзыве

Способов три, и браузеры пользуются ими по-разному.

• CRL — список отзыва. Центр сертификации публикует файл с серийными номерами отозванных сертификатов, адрес файла записан в сертификате.
• OCSP — запрос к серверу центра сертификации о конкретном сертификате. Ответ подписан центром и действует несколько дней.
• Вшитый ответ OCSP (OCSP stapling). Сайт сам заранее получает ответ OCSP и передаёт его браузеру при установке соединения.

Chromium, судя по исходникам (cert_verify_proc_builtin.cc и revocation_checker.cc), проверяет отзыв так:

1. Сначала сверяет цепочку со своим списком CRLSet. Это не полный список отзыва, а выборка серийных номеров и ключей, которую браузер получает обновлениями.
2. Затем смотрит вшитый ответ OCSP, если сайт его прислал. Ответ «отозван» даёт ошибку сразу, даже когда онлайн-проверка выключена.
3. Сам ходить за CRL и OCSP по сети он по умолчанию не будет. Это включается политикой EnableOnlineRevocationChecks, и даже тогда отказ «мягкий»: не дозвонился до сервера центра — сайт открывается. Для сертификатов от публично доверенных корней CRL при этом не скачивается, только OCSP.

Отсюда главный вывод: в Chromium ошибку ERR_CERT_REVOKED почти всегда вызывает либо CRLSet, либо ответ OCSP, который сайт сам вшил в соединение.

Стенд: когда браузер блокирует сайт

Мы выпустили свой корневой сертификат и два сертификата сайта, один из них отозвали с причиной keyCompromise. Корень добавили в доверенные, подняли nginx на пяти портах и сервер, который отдаёт CRL и ответы OCSP и записывает каждое обращение к себе.

Что видно из стенда:

• Chromium по сети за отзывом не ходил. Сервер OCSP и CRL за весь прогон Chromium не получил ни одного запроса. Отозванный сертификат без вшитого ответа браузер открыл как обычный.
• Firefox спрашивает сам. На каждый новый сертификат он отправлял POST-запрос к серверу OCSP из сертификата и блокировал отозванный, даже когда сайт ничего не вшивал.
• Отказ у Firefox мягкий. Когда мы выключили сервер OCSP, Firefox с чистым профилем открыл отозванный сертификат без предупреждения.
• Чужой ответ OCSP не считается. Ответ о другом серийном номере Chromium пропустил и открыл сайт, Firefox проверил сертификат по сети и заблокировал.
• Кнопки обхода нет ни у одного. В Firefox после «Advanced» нет «Accept the Risk and Continue», только ссылка на сертификат и код SEC_ERROR_REVOKED_CERTIFICATE. В Chromium есть скрытый обход для разработчиков, на стенде он сработал, но рядовому посетителю он не нужен: отозванный сертификат — как раз тот случай, когда защита права.

Для сверки мы один раз открыли публичный адрес revoked.badssl.com. Его сертификат выпустил Let's Encrypt 15 сентября 2026 года и в тот же день отозвал: серийный номер стоит в списке отзыва 74.crl. Адреса OCSP в сертификате нет. Chromium и Firefox с чистыми профилями открыли страницу: в них не было ни CRLSet, ни других загруженных списков, а CRL сами браузеры не скачивают. Обычный браузер с обновлёнными данными может повести себя иначе, но полагаться на это владельцу сайта нельзя.

Почему у Let's Encrypt нет OCSP

Let's Encrypt отказался от OCSP в 2025 году и объявил график в своём блоге: с 7 мая 2025 года адреса OCSP перестали записывать в новые сертификаты, вместо них стоят адреса CRL, а 6 августа 2025 года ответчики OCSP выключили. Причина — приватность: по запросу OCSP центр сертификации видит, какой сайт открывают с какого адреса.

Для владельца сайта на Let's Encrypt это значит две вещи. Вшивать ответ OCSP больше нечего, и директива ssl_stapling в nginx ничего не даёт. А проверять отзыв своего сертификата нужно по CRL: адрес списка записан в поле «Точки распространения списков отзыва».

Почему сертификат отзывают

Причину отзыва центр записывает в список отзыва. RFC 5280 (раздел 5.3.1) перечисляет коды: keyCompromise — ключ скомпрометирован, superseded — сертификат заменён, cessationOfOperation — домен больше не используется, affiliationChanged — изменились данные владельца, cACompromise — скомпрометирован сам центр, и другие.

На практике сертификат отзывают:

• сам владелец — при переезде, смене ключа, удалении сайта или по ошибке, например командой certbot revoke на старом сервере, где сертификат тот же, что и на новом;
• центр сертификации по заявлению — если закрытый ключ попал в открытый доступ: в репозиторий, в архив резервной копии на сайте;
• центр сертификации сам — если выпустил сертификат с нарушением правил. По Baseline Requirements CA/Browser Forum (раздел 4.9.1.1) центр обязан отозвать сертификат в течение 24 часов при компрометации ключа и в течение пяти дней в ряде других случаев;
• при смене владельца домена — по тем же правилам центр отзывает сертификат, если узнал, что владелец больше не управляет доменом.

Что вызывает ошибку

На стороне сайта:

• сертификат отозван, а на сервере стоит он же;
• сертификат перевыпустили, но старый остался на одном из серверов: на адресе с www, на балансировщике, на CDN или на втором сервере;
• веб-сервер вшивает старый сохранённый ответ OCSP. На нашем стенде nginx с директивой ssl_stapling_file отдавал браузеру сохранённый в файле ответ «отозван»;
• в CRLSet попал ключ промежуточного сертификата, и браузер блокирует все сертификаты под ним, а не только ваш.

На стороне пользователя:

• антивирус с проверкой защищённых соединений или корпоративный прокси подставляет свой сертификат, и с ним что-то не так;
• сайт открывается через сеть, где соединение перехватывают, — в гостевом Wi-Fi или через сомнительный VPN.

Сбитые часы на компьютере обычно дают другую ошибку — NET::ERR_CERT_DATE_INVALID, а не отзыв.

Как исправить ошибку посетителю

Сначала определите, ваша ли это проблема. Попробуйте открыть тот же адрес с телефона через мобильный интернет. Если ошибка есть и там, сертификат отозван у сайта, и решение за владельцем: на вашем устройстве её не исправить. Если сайт не открывается только на одном компьютере, выполните следующие шаги по порядку и после каждого снова попробуйте зайти.

1. Проверьте с другого устройства и другой сети. Если сайт открывается везде, кроме вашего компьютера, причина в нём: в программах, которые встраиваются в соединение.
2. Отключите на минуту проверку защищённых соединений в антивирусе. Такие программы расшифровывают трафик и подставляют свой сертификат. Помогло — добавьте сайт в исключения антивируса, а защиту включите обратно.
3. Отключите VPN, прокси и расширения браузера. Проще всего открыть сайт в режиме инкогнито, где расширения выключены. Открылось — включайте расширения по одному и удалите то, после которого ошибка возвращается.
4. Обновите браузер до последней версии. Вместе с обновлением приходят свежие списки отзыва и корневые сертификаты.
5. Убедитесь, что дата и время на устройстве верные. На отзыв они обычно не влияют, но неправильная дата ломает проверку остальных сертификатов и мешает понять, в чём дело.
6. Сообщите владельцу сайта. Укажите код ошибки и время, когда она появилась: часто владелец узнаёт об отзыве только по сообщениям посетителей.

Очистка кэша и cookies, попытка сбросить настройки сети и смена DNS к этой ошибке отношения не имеют: сертификат браузер получает заново при каждом соединении, и очистка файлов браузера ничего не поменяет. Вводить на таком сайте пароль, данные карты или паспорта нельзя, даже если другой браузер его открыл.

Если ошибка только на одном компьютере

Иногда отозванным оказывается не сертификат сайта, а тот, что подставила программа на вашем компьютере. Так бывает в трёх случаях:

• Антивирус с проверкой HTTPS. Он создаёт для каждого сайта свой сертификат, подписанный своим корнем. Если корень устарел или его отозвали, ошибка появится на большинстве сайтов сразу.
• Корпоративная сеть. На рабочем компьютере шифрование часто перехватывает прокси организации. Исправить конфигурацию может только администратор — напишите ему, какой адрес и с какой ошибкой не открывается.
• Приложения для «ускорения» и родительского контроля. Они тоже могут встраиваться в соединение. Удалите или отключите их на время проверки.

Системные корневые сертификаты на эту ошибку почти не влияют: Chromium давно проверяет цепочку своим кодом, а отзыв узнаёт из CRLSet. Поэтому переустановка браузера помогает редко, а обновление — чаще.

Как исправить владельцу сайта

1. Узнайте серийный номер и адрес списка отзыва. В терминале:

   echo | openssl s_client -connect ваш-сайт.ru:443 -servername ваш-сайт.ru 2>/dev/null | openssl x509 -noout -serial -ext crlDistributionPoints,authorityInfoAccess
   

   Проверьте адреса с www и без: на них бывают разные сертификаты.

2. Проверьте, есть ли номер в CRL. Скачайте список по адресу из предыдущего шага и найдите в нём серийный номер:

   curl -s http://адрес-списка.crl -o ca.crl
   openssl crl -inform DER -in ca.crl -noout -text | grep -A3 "Serial Number: НОМЕР"
   

   Если номер нашёлся, рядом будут дата отзыва и причина. Если у сертификата есть адрес OCSP, статус покажет и openssl ocsp -issuer промежуточный.pem -cert сертификат.pem -url адрес-ocsp.

3. Выпустите новый сертификат. При причине keyCompromise или любом подозрении на утечку — с новым закрытым ключом. Для Let's Encrypt — certbot renew --force-renewal: certbot по умолчанию создаёт новый ключ при каждом выпуске, если не задан --reuse-key. Подробнее о выпуске — в статье про SSL-сертификат сайта.

4. Установите его везде, где работает домен, и перезапустите веб-сервер. nginx и Apache читают сертификат при запуске.

5. Проверьте вшитый ответ OCSP. Команда openssl s_client -connect ваш-сайт.ru:443 -status покажет строку Cert Status. Если там revoked, сервер отдаёт старый ответ: замените файл ssl_stapling_file или перезапустите nginx, чтобы он запросил новый.

6. Выясните, кто отозвал. Если отзыв неожиданный, напишите в центр сертификации и проверьте, не утёк ли ключ: где хранились копии privkey.pem, кто имел доступ к серверу.

Ошибка и SEO

Отзыв сертификата не меняет код ответа сервера: страница по-прежнему отдаёт 200, просто браузер не открывает соединение. Как с отозванным сертификатом поступает робот Google или Яндекса, поисковики в своей документации отдельно не описывают, и мы это не проверяли. Посетитель из поиска, который увидел экран без кнопки «Перейти», уходит обратно в выдачу, а заявки и покупки с сайта прекращаются. Поэтому отзыв нужно исправлять в тот же день, а не ждать планового продления.

Чем ERR_CERT_REVOKED отличается от похожих ошибок

Границы замера

• Chromium 149 и Firefox 151 на Linux, сборки из Playwright с чистыми профилями. Windows, macOS, Яндекс Браузер и телефоны мы не проверяли.
• Свой корень и свои сертификаты: CRLSet к ним не применяется, поэтому блокировку через CRLSet мы видели только в исходниках.
• Сайт revoked.badssl.com открыли по одному разу из Германии.
• Онлайн-проверку в Chromium через политику EnableOnlineRevocationChecks мы не включали.

Источники

• Chromium: net_error_list.h, cert_verify_proc_builtin.cc, revocation_checker.cc, crl_set.h — github.com/chromium
• RFC 5280, раздел 5.3.1 «Reason Code» — rfc-editor.org
• RFC 6960 «Online Certificate Status Protocol» — rfc-editor.org
• Let's Encrypt: «Ending OCSP Support in 2025» — letsencrypt.org
• CA/Browser Forum Baseline Requirements, раздел 4.9.1.1 — cabforum.org

Похожие ошибки

• Ваше подключение не защищено — все ошибки сертификата на одном экране.
• NET::ERR_CERT_DATE_INVALID — сертификат просрочен или врут часы.
• NET::ERR_CERT_AUTHORITY_INVALID — браузер не доверяет издателю.
• ERR_SSL_PROTOCOL_ERROR — соединение не установилось.

Коротко

• NET::ERR_CERT_REVOKED — центр сертификации отозвал сертификат сайта раньше срока, и браузер это увидел.
• Кнопки «Перейти на сайт» нет ни в Chromium, ни в Firefox.
• Chromium узнаёт об отзыве из CRLSet и из ответа OCSP, который вшил сам сайт; по сети за отзывом он по умолчанию не ходит. Firefox спрашивает сервер OCSP сам.
• Let's Encrypt с августа 2025 года OCSP не поддерживает, отзыв его сертификатов виден только в CRL.
• Посетителю — проверить с другой сети и отключить проверку соединений в антивирусе; если ошибка везде, исправлять владельцу.
• Владельцу — выпустить новый сертификат с новым ключом, поставить его на все серверы и проверить вшитый ответ OCSP.