Ошибка Chrome ERR_CERT_AUTHORITY_INVALID — как найти и исправить

Кратко: ошибка net::ERR_CERT_AUTHORITY_INVALID в Chrome означает, что браузер не доверяет центру сертификации или цепочке сертификатов сайта. Для пользователей — проверьте дату/время, очистите кэш, обновите браузер и временно отключите HTTPS-сканирование в антивирусе. Для владельцев сайта — убедитесь, что установлен правильный сертификат с промежуточными сертификатами, обновляйте срок действия и используйте доверенный CA вроде Let’s Encrypt или платного провайдера.

Что это за ошибка и почему она появляется

Ошибка net::ERR_CERT_AUTHORITY_INVALID возникает, когда Google Chrome не может проверить подлинность SSL/TLS‑сертификата сайта. Проще говоря, браузер не доверяет центру сертификации (CA) или цепочке сертификатов, которые предъявляет сервер. Браузер показывает предупреждение, чтобы защитить пользователя от поддельных или перехваченных соединений.

Краткое определение термина

• CA (центр сертификации): организация, выпускающая SSL/TLS сертификаты. Если браузер не знает или не доверяет CA, он помечает сертификат как недействительный.

Частые причины ошибки

• Истёк срок действия сертификата.
• Сертификат самоподписан (self-signed) и не добавлен в доверенные корневые хранилища.
• Отсутствует или неверно передаётся промежуточный сертификат (цепочка неполная).
• Сертификат выдан непроверяемым или недоверенным центром сертификации.
• На клиенте неверные системные дата и время.
• Антивирус/прокси перехватывает HTTPS и подставляет свой сертификат (man-in-the-middle при HTTPS-сканировании).
• Плохая конфигурация сервера (неправильный ключ, неправильный конфиг HTTPS).

Важно: это предупреждение безопасности — не игнорируйте его без понимания последствий.

Быстрая диагностика для пользователя

1. Проверьте дату и время на устройстве — если они сильно отличаются, сертификат покажется недействительным.
2. Откройте страницу в другом браузере или на другом устройстве — та же ошибка укажет на проблему на стороне сайта.
3. Попробуйте режим инкогнито и очистку кэша/куки.
4. Отключите временно HTTPS‑сканирование в антивирусе или прокси и повторите запрос.
5. Нажмите на значок замка в адресной строке и просмотрите сведения о сертификате: кому выдан, кем выдан, срок действия и цепочка.

Подробные шаги для пользователей (Windows / Android / macOS)

Очистка кеша и куки в Google Chrome

1. Откройте Google Chrome.
2. Нажмите меню (три точки) → Дополнительные инструменты → Очистить данные о браузере.
3. Выберите «Временной диапазон» — чтобы удалить всё, выберите «За всё время».
4. Отметьте «Файлы cookie и данные сайтов» и «Изображения и другие файлы, сохранённые в кэше».
5. Нажмите “Очистить данные”, перезапустите браузер.

Обновление Google Chrome

1. Откройте Google Chrome.
2. Меню (три точки) → Справка → О браузере Google Chrome.
3. Дождитесь проверки обновлений и установки, затем перезапустите браузер.

Если антивирус перехватывает HTTPS

Многие антивирусы вставляют свой сертификат для проверки трафика. Отключите опцию “сканирование защищённых соединений” в настройках антивируса и проверьте сайт снова. Если после отключения проблема исчезла — причина в перехвате; рассмотрите добавление корневого сертификата антивируса в доверенные (только в контролируемой среде).

Шаги для владельцев сайта и администраторов

Ниже — пошаговый план и чеклист для системных администраторов и владельцев сайтов.

1. Проверка срока действия и соответствия домена

• Убедитесь, что сертификат не просрочен.
• Common Name / Subject Alternative Name (CN/SAN) должны включать ваш домен.
• Если сертификат выдан для www.example.com, а вы заходите на example.com, нужен сертификат с обеими формами.

2. Проверка цепочки сертификатов (intermediate chain)

Проблемы с промежуточными сертификатами — одна из самых частых причин. Сервер должен отдавать полный цепочку: ваш сертификат + промежуточные сертификаты + (необязательно) корневой.

Как проверить с сервера (openssl):

openssl s_client -connect yoursite.example:443 -showcerts

Из вывода видно, какие сертификаты отправляет сервер. Если промежуточных нет — браузер выдаст ошибку.

3. Правильная конфигурация для популярных серверов

• Nginx: указывайте файл с полным цепочником (fullchain) в ssl_certificate, а приватный ключ в ssl_certificate_key.

Пример:

server {
  listen 443 ssl;
  server_name example.com;
  ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

• Apache: используйте SSLCertificateFile для сертификата и SSLCertificateChainFile для промежуточных (или SSLCertificateFile с объединённым цепочником).

4. Используйте доверенный CA

• Для большинства сайтов хорошим выбором будет Let’s Encrypt — бесплатно и широко поддерживается.
• Для организаций с особыми требованиями рассматривайте платные CA (DigiCert, Sectigo и др.).

5. Автоматизация продления

Настройте автоматическое обновление сертификатов (например, Certbot для Let’s Encrypt). Это снижает риск истечения срока действия.

6. Тестирование безопасности и соответствия

• Пройдите проверку SSL Labs (Qualys SSL Labs) для полного анализа конфигурации.
• Проверьте поддержку современных протоколов (TLS 1.2/1.3) и отсутствие слабых шифров.

Дополнительные сценарии и как их решать

• Самоподписанные сертификаты: не используйте в продакшене. Для внутренней инфраструктуры — добавьте корневой сертификат в доверенное хранилище клиентов.
• Корпоративные прокси: согласуйте с IT‑отделом процедуру установки доверенного сертификата на рабочие станции.
• HSTS и кешированные ошибки: при повторной ошибке проверьте, не сохранился ли HSTS в браузере — иногда помогает очистка профиля браузера или временное отключение политики HSTS.

Ментальные модели и чеклист принятия решения

Когда вы видите ошибку, ответьте на последовательные вопросы:

1. Проявляется ли ошибка на всех устройствах? Если да — проблема на стороне сервера.
2. Соответствует ли время/дата на клиенте? Если нет — исправьте и повторите.
3. Отдаёт ли сервер полный цепочку сертификатов? Если нет — исправьте конфигурацию.
4. Использует ли сайт доверенный CA? Если нет — замените сертификат на выданный доверенным CA.

Роль‑ориентированный чеклист

• Владелец сайта: проверьте срок, провайдер сертификата, автоматизацию продления.
• Сисадмин: проверьте конфигурацию сервера, тесты openssl и SSL Labs.
• Пользователь: проверьте дату/время, кэш, антивирус, попробуйте другой браузер.

Диагностическое дерево

flowchart TD
  A[Ошибка ERR_CERT_AUTHORITY_INVALID] --> B{Появляется на всех устройствах?}
  B -- Да --> C{Сервер отдает цепочку?}
  B -- Нет --> D[Проверьте дату/время и антивирус на клиенте]
  C -- Нет --> E[Добавить промежуточные сертификаты на сервере]
  C -- Да --> F{Сертификат выдан доверенным CA?}
  F -- Нет --> G[Заменить сертификат на выданный доверенным CA]
  F -- Да --> H[Проверить антивирус/прокси и HSTS]

Критерии приёмки

Чтобы считать проблему решённой, выполните проверки:

• Страница открывается в Chrome без предупреждений на трёх разных устройствах.
• openssl s_client показывает полную цепочку сертификатов.
• SSL Labs выдаёт рейтинг A или выше по ключевым пунктам (запросите отчет).
• Автоматическое продление сертификатов настроено и протестировано.

Тесты и приемочные кейсы

• TC1: Сайт с корректным fullchain проходит проверку openssl и не вызывает предупреждений.
• TC2: После обновления сертификата клиентский браузер показывает новый срок действия.
• TC3: При отключении HTTPS‑сканирования антивируса предупреждение пропадает.

Безопасность и конфиденциальность

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

Частые вопросы

Что делать, если я временно должен попасть на сайт с ошибкой

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

Почему некоторые браузеры показывают ошибку, а другие нет

Разные браузеры могут иметь разные наборы доверенных корневых центров сертификации и очередность проверки цепочки. Chrome использует системное хранилище сертификатов на Windows и macOS, а на Linux — своё поведение в зависимости от сборки.

Полезные ресурсы и команды

• Проверка с OpenSSL: openssl s_client -connect example.com:443 -showcerts
• Certbot для Let’s Encrypt: https://certbot.eff.org/
• SSL Labs: https://www.ssllabs.com/ssltest/

Итог и рекомендации

• Для пользователей: сначала проверьте локальные причины — дата/время, кэш, антивирус, обновления браузера.
• Для владельцев сайтов: убедитесь, что сервер отдаёт полный цепочку сертификатов, используйте доверенный CA и автоматизируйте обновление.

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

Если вы устраните проблему по одному из методов выше, напишите кратко, какой способ сработал, чтобы другие могли быстрее найти решение.