Как исправить ошибку NET::ERR_CERT_AUTHORITY_INVALID

NET::ERR_CERT_AUTHORITY_INVALID — это сбой TLS-рукопожатия на уровне браузера, который возникает, когда сертификат, предоставленный веб-сервером, не может быть прослежен до корневого Центра сертификации (CA), которому доверяет встроенное хранилище доверия браузера. Браузер разрывает соединение до обмена какими-либо данными, отображая эту ошибку для предотвращения атак типа «человек посередине» (MITM), перехвата данных или трафика с поддельного сервера.

Это не косметическое предупреждение. Это жёсткий сбой криптографической проверки. Браузер проверил цепочку сертификатов, попытался проверить каждое звено вплоть до доверенного корня и обнаружил, что цепочка нарушена, отсутствует или криптографически недействительна. Точное понимание того, где именно разрывается цепочка, — это разница между пятиминутным исправлением и часами неверной диагностики.

Что на самом деле вызывает эту ошибку

Большинство документации перечисляет поверхностные причины. Реальная картина более сложна, и каждая первопричина требует своего пути устранения.

Самоподписанные сертификаты

Самоподписанный сертификат — это сертификат, в котором издатель и субъект идентичны: сервер подписал собственный сертификат, а не обратился к доверенному CA. Они стандартны в локальных средах разработки, внутренних промежуточных серверах и частной инфраструктуре. Ни одно публичное хранилище доверия браузера их не распознаёт, поэтому проверка цепочки немедленно завершается неудачей.

Важный нюанс: Даже если вы добавите самоподписанный сертификат в хранилище доверия ОС, некоторые браузеры (в частности, Chrome на определённых платформах) используют собственное хранилище сертификатов и всё равно отклонят его, если явно не настроено иное.

Истёкший SSL/TLS-сертификат

Каждый сертификат содержит поля `notBefore` и `notAfter`, закодированные в его структуре X.509. Как только системные часы пересекают временну́ю метку `notAfter`, сертификат становится криптографически недействительным независимо от того, как он был выдан. Браузеры строго соблюдают это требование.

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

Неполная цепочка сертификатов (отсутствует промежуточный CA)

Это наиболее часто неверно диагностируемая причина в производственных средах. Доверенный корневой CA не подписывает конечные сертификаты напрямую. Он подписывает промежуточные CA, которые затем подписывают ваш сертификат. При установке SSL-сертификата на сервер необходимо установить полную цепочку: ваш конечный сертификат плюс все промежуточные сертификаты, объединённые по порядку.

Если промежуточный сертификат отсутствует в TLS-ответе сервера, большинство браузеров не могут завершить обход цепочки до доверенного корня. Firefox несколько более снисходителен в этом отношении, поскольку кэширует промежуточные сертификаты из предыдущих сессий (получение AIA), но Chrome и Edge завершатся с жёсткой ошибкой.

Как проверить: Выполните `openssl s_client -connect yourdomain.com:443 -showcerts` и проверьте, возвращается ли полная цепочка.

Несоответствие Common Name или SAN сертификата

Если сертификат был выдан для `www.example.com`, но пользователь обращается к `example.com` (или к поддомену, не охваченному wildcard-сертификатом), браузер выдаст связанную, но отдельную ошибку. Однако в некоторых конфигурациях это проявляется как ошибка недействительного центра сертификации, а не ошибка несоответствия имени, особенно со старыми форматами сертификатов, в которых отсутствуют Subject Alternative Names (SAN).

Расхождение часов на стороне клиента

TLS-сертификаты ограничены по времени. Если часы клиентской машины установлены на дату до поля `notBefore` сертификата или после его поля `notAfter`, браузер отклонит его. Это крайне распространено на виртуальных машинах, недавно подготовленных серверах или машинах, которые были выключены на длительное время без синхронизации NTP.

SSL-инспекция программным обеспечением безопасности

Корпоративные межсетевые экраны, пакеты безопасности конечных точек и некоторые антивирусные продукты выполняют SSL/TLS-инспекцию (также называемую перехватом HTTPS). Они завершают TLS-соединение на устройстве безопасности, проверяют открытый текст, а затем повторно шифруют его с использованием динамически сгенерированного сертификата, подписанного собственным CA устройства. Если этот CA устройства не находится в хранилище доверия браузера, каждый HTTPS-сайт будет вызывать эту ошибку.

Устаревшее хранилище корневых сертификатов

На старых операционных системах (Windows 7 без обновлений, устаревшие дистрибутивы Linux) системный пакет корневых CA может не включать новые корневые сертификаты. Например, ISRG Root X1 от Let’s Encrypt вызвал массовые ошибки на Android 7 и ниже, а также на необновлённых системах Windows, когда перекрёстная подпись DST Root CA X3 истекла в сентябре 2021 года.

Сравнение первопричин

Пошаговые исправления

Шаг 1: Синхронизация системной даты и времени

Это самое быстрое исправление, когда ошибка внезапно появляется на машине, которая ранее работала нормально.

Windows:

1. Откройте Параметры > Время и язык > Дата и время.
2. Включите Устанавливать время автоматически и Устанавливать часовой пояс автоматически.
3. Нажмите Синхронизировать сейчас в разделе «Синхронизация часов».
4. Если автоматическая синхронизация не удаётся, откройте командную строку от имени администратора и выполните: `w32tm /resync /force`

macOS:

1. Откройте Системные настройки > Основные > Дата и время.
2. Включите Устанавливать дату и время автоматически и выберите ближайший NTP-сервер (например, `time.apple.com`).
3. Если проблема сохраняется, выполните в Терминале: `sudo sntp -sS time.apple.com`

Linux (сервер или рабочий стол):

“`bash

sudo timedatectl set-ntp true

sudo systemctl restart systemd-timesyncd

timedatectl status

“`

После синхронизации перезапустите браузер и повторите попытку.

Шаг 2: Очистка кэша браузера, файлов cookie и кэшированных сертификатов

Браузеры кэшируют политики HSTS (HTTP Strict Transport Security) и данные сертификатов. Устаревшая запись в кэше может сохранять ошибку даже после устранения основной проблемы.

Google Chrome:

1. Перейдите по адресу `chrome://settings/clearBrowserData`.
2. Установите временной диапазон За всё время.
3. Отметьте Файлы cookie и другие данные сайтов и Кэшированные изображения и файлы.
4. Нажмите Удалить данные.

Для очистки кэша HSTS в Chrome перейдите по адресу `chrome://net-internals/#hsts`, введите домен в поле «Удалить политики безопасности домена» и нажмите Удалить.

Mozilla Firefox:

1. Откройте Настройки > Приватность и защита.
2. В разделе Куки и данные сайтов нажмите Удалить данные.
3. Также очистите Кэшированное веб-содержимое.

Microsoft Edge:

1. Перейдите по адресу `edge://settings/clearBrowserData`.
2. Выберите За всё время и очистите кэшированные данные и файлы cookie.

Шаг 3: Определение и отключение SSL-инспекции

Если вы находитесь в корпоративной сети или используете продукт безопасности для конечных точек, SSL-инспекция является главным подозреваемым.

1. Нажмите на значок замка (или значок предупреждения) в адресной строке браузера.
2. Проверьте сведения о сертификате. Если издателем является ваш антивирусный вендор (например, «Avast Root», «Kaspersky Anti-Virus», «ESET SSL Filter CA»), а не публичный CA, такой как DigiCert, Let’s Encrypt или Sectigo, значит SSL-инспекция активна.
3. В настройках антивируса или межсетевого экрана найдите Сканирование HTTPS, Фильтрация SSL или Веб-щит и отключите его.
4. Либо добавьте корневой сертификат CA устройства в хранилище доверия браузера.

Не отключайте программное обеспечение безопасности навсегда. Повторно включите его после тестирования или настройте исключения для конкретных доверенных доменов.

Шаг 4: Проверка и восстановление цепочки сертификатов на стороне сервера (для администраторов серверов)

Это правильное исправление для производственных веб-сайтов, где посетители видят ошибку.

Диагностика цепочки:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -E "Issuer:|Subject:"

“`

Или используйте полную проверку цепочки:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts

“`

Подсчитайте количество возвращённых сертификатов. Вы должны увидеть как минимум два (конечный + промежуточный). Если отображается только один, промежуточный сертификат отсутствует.

Исправление в Apache (`httpd.conf` или файл виртуального хоста):

“`apache

SSLCertificateFile /etc/ssl/certs/yourdomain.crt

SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

“`

Исправление в Nginx (`nginx.conf` или блок сервера):

Nginx требует объединения полной цепочки в один файл:

“`bash

cat yourdomain.crt intermediate.crt > fullchain.pem

“`

Затем укажите его:

“`nginx

ssl_certificate /etc/ssl/certs/fullchain.pem;

ssl_certificate_key /etc/ssl/private/yourdomain.key;

“`

После редактирования всегда проверяйте конфигурацию перед перезапуском:

“`bash

Apache

apachectl configtest

Nginx

nginx -t

“`

Затем перезагрузите службу:

“`bash

sudo systemctl reload apache2

or

sudo systemctl reload nginx

“`

Если вы работаете в управляемой среде, VPS с cPanel предоставляет графический интерфейс в разделе Менеджер SSL/TLS, где вы можете вставить сертификат, закрытый ключ и пакет CA напрямую, не редактируя файлы конфигурации вручную.

Шаг 5: Обновление или замена истёкшего сертификата

Если срок действия сертификата истёк, обходного пути на стороне клиента не существует. Сервер должен предоставить действительный сертификат.

Для Let’s Encrypt (Certbot):

“`bash

sudo certbot renew –dry-run

sudo certbot renew

sudo systemctl reload nginx # or apache2

“`

Для сертификатов, управляемых вручную: Получите новый сертификат от вашего CA, загрузите его через панель управления и убедитесь, что цепочка нового сертификата полна. Если вам нужен доверенный сертификат для производственного домена, SSL-сертификаты от признанного CA полностью устраняют проблему самоподписанных сертификатов.

Автоматизируйте обновления: Сертификаты Let’s Encrypt истекают каждые 90 дней. Добавьте задание cron или используйте таймеры systemd для автоматизации обновления:

“`bash

0 3 * * * /usr/bin/certbot renew –quiet –post-hook "systemctl reload nginx"

“`

Шаг 6: Добавление самоподписанного сертификата в доверенные для внутреннего использования

Если вы используете внутренние инструменты, сервер разработки или службу частной сети, где замена сертификата нецелесообразна, вы можете добавить самоподписанный сертификат в хранилище доверия ОС.

Windows:

1. Экспортируйте сертификат из браузера (нажмите на предупреждение > Сертификат > Состав > Копировать в файл).
2. Откройте `certmgr.msc`.
3. Перейдите в Доверенные корневые центры сертификации > Сертификаты.
4. Щёлкните правой кнопкой мыши > Все задачи > Импорт и импортируйте сертификат.

macOS:

“`bash

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.crt

“`

Linux (Debian/Ubuntu):

“`bash

sudo cp cert.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

“`

Важно: Chrome на Linux и Windows использует хранилище доверия ОС для большинства целей, но также поддерживает собственную базу данных NSS. Если Chrome всё равно отклоняет сертификат после обновления хранилища ОС, импортируйте его напрямую через `chrome://settings/certificates`.

Шаг 7: Обновление браузера и операционной системы

Устаревший браузер может не иметь новых корневых сертификатов CA или не поддерживать текущие версии протокола TLS (минимум TLS 1.2 теперь обязателен; предпочтителен TLS 1.3).

Chrome: Перейдите по адресу `chrome://settings/help`. Chrome обновляется автоматически; если обновление ожидает установки, оно будет применено здесь.

Firefox: Перейдите в Справка > О Firefox. Firefox проверит наличие обновлений и применит их.

Операционная система: В Windows убедитесь, что Центр обновления Windows актуален. На серверах Linux выполните:

“`bash

sudo apt update && sudo apt upgrade ca-certificates openssl

“`

Это особенно важно для серверов, работающих на более старых дистрибутивах, где пакет CA-bundle (пакет `ca-certificates`) не был обновлён для включения новых корневых CA.

Шаг 8: Сброс сетевого стека и очистка DNS

Неправильные конфигурации на сетевом уровне, повреждённые кэши DNS или устаревшие записи Winsock иногда могут способствовать сбоям согласования TLS.

Windows (запустите командную строку от имени администратора):

“`cmd

netsh int ip reset

netsh winsock reset

ipconfig /release

ipconfig /renew

ipconfig /flushdns

“`

Перезагрузите машину после выполнения этих команд.

macOS:

“`bash

sudo dscacheutil -flushcache

sudo killall -HUP mDNSResponder

“`

Linux:

“`bash

sudo systemd-resolve –flush-caches

or for systems using nscd:

sudo service nscd restart

“`

Шаг 9: Обход предупреждения (только для тестирования)

Это исключительно диагностический инструмент, а не решение. Используйте его только для подтверждения того, что ошибка связана с сертификатом, а не с сетью или приложением, или при обращении к заведомо безопасному внутреннему серверу во время разработки.

Chrome: Нажмите Дополнительно на странице ошибки, затем Перейти на сайт [домен] (небезопасно).

Firefox: Нажмите Дополнительно, затем Принять риск и продолжить.

Никогда не обходите это предупреждение на сайтах, обрабатывающих аутентификацию, платежи или персональные данные. Предупреждение существует потому, что соединение действительно не проверено.

Проверка исправления

После применения любых изменений на стороне сервера проверьте результат с помощью этих инструментов, прежде чем объявлять проблему решённой:

• SSL Labs SSL Test (`ssllabs.com/ssltest/`): Предоставляет полный анализ цепочки, оценку поддержки протоколов и выявляет конкретные слабые места конфигурации.
• `openssl s_client`: Проверка из командной строки, показывающая именно то, что сервер предоставляет во время TLS-рукопожатия.
• `curl -vI https://yourdomain.com`: Быстрая проверка, отображающая детали TLS-рукопожатия и результат проверки сертификата.
• `whatsmychaincert.com`: Специально диагностирует отсутствующие промежуточные сертификаты.

Выбор правильной хостинговой инфраструктуры для предотвращения повторных ошибок

Многие ошибки сертификатов возникают из-за ограничений инфраструктуры, а не из-за ошибок администратора. Среды общего хостинга иногда ограничивают способы настройки цепочек сертификатов или ограничивают доступ к файлам конфигурации веб-сервера. Если вы регулярно сталкиваетесь с проблемами цепочки или обновления, переход на среду VPS-хостинга даёт вам полный контроль над вашим TLS-стеком — включая возможность напрямую настраивать Nginx или Apache, автоматизировать обновления Certbot и устанавливать пользовательские пакеты CA.

Для высоконагруженных рабочих нагрузок или рабочих нагрузок, требующих соответствия нормативным требованиям, где управление сертификатами критически важно, выделенные серверы устраняют переменные многопользовательской среды, которые могут усложнить настройку SSL. Если вы управляете несколькими доменами или поддоменами, панель управления VPS упрощает развёртывание сертификатов для всех из них из единого интерфейса.

Матрица решений: какое исправление применимо к вашей ситуации

Практический контрольный список ключевых выводов

• Прежде чем предпринимать какие-либо действия, определите, является ли ошибка клиентской (часы, кэш, SSL-инспекция) или серверной (истёкший сертификат, отсутствующий промежуточный).
• Выполните `openssl s_client -connect domain:443 -showcerts` в качестве первого диагностического шага при любом расследовании на стороне сервера.
• Всегда объединяйте полную цепочку сертификатов (конечный + все промежуточные) в конфигурации вашего веб-сервера.
• Автоматизируйте обновление сертификатов с помощью заданий cron Certbot или аналогичных средств — ручное обновление гарантированно приведёт к будущим сбоям.
• После любого изменения сертификата выполните проверку с помощью SSL Labs перед закрытием инцидента.
• Никогда не отключайте SSL-сканирование антивируса навсегда; вместо этого настройте исключения или правильно установите сертификат CA прокси.
• На серверах Linux поддерживайте пакеты `ca-certificates` и `openssl` в актуальном состоянии, чтобы хранилище корневых сертификатов отражало текущие доверенные CA.
• Используйте `chrome://net-internals/#hsts` для очистки записей кэша HSTS, когда сертификат домена был законно изменён, а Chrome по-прежнему отказывается подключаться.

Часто задаваемые вопросы

В чём разница между NET::ERR_CERT_AUTHORITY_INVALID и NET::ERR_CERT_COMMON_NAME_INVALID?

`ERR_CERT_AUTHORITY_INVALID` означает, что издатель сертификата не является доверенным — цепочка не может быть проверена. `ERR_CERT_COMMON_NAME_INVALID` означает, что сертификат выдан доверенным CA, но для другого домена, а не для того, к которому осуществляется доступ. Они требуют разных исправлений: первая требует нового сертификата от доверенного CA или восстановления цепочки; вторая требует перевыпуска сертификата с правильными Subject Alternative Names.

Может ли NET::ERR_CERT_AUTHORITY_INVALID появиться даже при наличии действительного платного SSL-сертификата?

Да. Платный сертификат от доверенного CA всё равно вызовет эту ошибку, если промежуточный сертификат не включён в TLS-ответ сервера. Браузер не всегда может автоматически получить отсутствующие промежуточные сертификаты (получение AIA ненадёжно), поэтому цепочка должна быть явно настроена на сервере.

Почему эта ошибка появляется только в Chrome, но не в Firefox?

Firefox поддерживает собственное хранилище доверия сертификатов и также кэширует промежуточные сертификаты из предыдущих успешных соединений (механизм, называемый получением AIA с кэшированием). Chrome более строго полагается на хранилище доверия ОС и цепочку, предоставленную сервером. Отсутствующий промежуточный сертификат, который Firefox кэшировал из предыдущей сессии, всё равно вызовет сбой в Chrome.

Безопасно ли нажимать «Всё равно перейти» при предупреждении NET::ERR_CERT_AUTHORITY_INVALID?

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

Как предотвратить повторное возникновение этой ошибки на моём производственном сервере?

Автоматизируйте обновление сертификатов (Certbot с заданием cron или таймером systemd), отслеживайте истечение срока действия сертификатов с помощью внешнего инструмента (UptimeRobot, Zabbix или `ssl-cert-check`), всегда развёртывайте полную цепочку сертификатов и поддерживайте активную синхронизацию NTP вашего сервера. Для сред, где ручное управление подвержено ошибкам, рассмотрите хостинговую платформу с интегрированным управлением сертификатами — VPS с cPanel автоматически обрабатывает обновления AutoSSL для всех размещённых доменов.