ERR_CERT_AUTHORITY_INVALID

Что это значит

Chrome не смог построить цепочку от сертификата сайта до корневого сертификата, которому доверяет. Этот проход и есть проверка пути из RFC 5280, пункт 6, а доверенный корневой сертификат подаётся ей на вход (пункт 6.1.1). Через отладочный прокси причина почти всегда одна: прокси подписывает сертификаты собственным центром сертификации, а его корневой сертификат не установлен. Соседние ошибки говорят о другом: ERR_CERT_COMMON_NAME_INVALID указывает на несовпадение имени (RFC 9110, пункт 4.3.4, который отсылает к RFC 6125, пункт 6), ERR_CERT_DATE_INVALID — на часы или срок действия (RFC 5280, пункт 4.1.2.5), ERR_CERT_REVOKED — на отзыв сертификата (пункт 6.3).

Как исправить

Корневой сертификат прокси надо установить в то хранилище, куда браузер действительно смотрит. Хранилище не одно.

macOS. Откройте .pem или .cer двойным щелчком. Он попадёт в «Связку ключей», обычно в связку «Вход». Дальше нужен второй шаг: откройте сертификат, разверните «Доверие» и в «При использовании этого сертификата» поставьте «Всегда доверять». Без этого сертификат лежит в связке, но доверия к нему нет.

Из терминала, на всю систему:

sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain proxy-ca.pem

Windows. Запустите «Установить сертификат» и поменяйте оба значения по умолчанию. Мастер открывается на «Текущий пользователь» и на «Автоматически выбрать хранилище на основе типа сертификата». Переключите на «Локальный компьютер», затем выберите «Поместить все сертификаты в следующее хранилище» → «Доверенные корневые центры сертификации». Автовыбор туда не положит.

То же самое в PowerShell, запущенном от администратора:

Import-Certificate -FilePath .\proxy-ca.cer `
  -CertStoreLocation Cert:\LocalMachine\Root

Linux. У дистрибутивов пути разные. В Debian и Ubuntu файл должен быть в формате PEM и иметь расширение .crt, иначе update-ca-certificates его не обработает:

# Debian / Ubuntu
sudo cp proxy-ca.crt /usr/local/share/ca-certificates/proxy-ca.crt
sudo update-ca-certificates

# Fedora / RHEL
sudo cp proxy-ca.pem /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Потом перезапустите браузер целиком. Chrome кеширует результат проверки, и открытая вкладка продолжит показывать ошибку.

Почему может всё равно не работать

У Firefox своё хранилище. «Настройки» → «Приватность и защита» → «Сертификаты» → «Просмотр сертификатов» → «Центры сертификации» → «Импортировать». Флаг security.enterprise_roots.enabled в about:config заставляет Firefox читать и системное хранилище, но только на Windows и macOS. На Linux этот флаг ничего не даёт, поэтому импортируйте файл вручную.

У Chrome свой список корневых сертификатов. Chrome Root Store включён по умолчанию с версии 108 на Windows и macOS, с 114 на Linux и ChromeOS, с 115 на Android. Он заменяет только список публичных центров: сертификат, который добавили вы или администратор, по-прежнему работает на TLS-соединении. Так что инструкция выше действует.

Node.js, Python, curl и Java туда вообще не смотрят. У каждого свой список: NODE_EXTRA_CA_CERTS=/path/ca.pem, REQUESTS_CA_BUNDLE или SSL_CERT_FILE, curl --cacert ca.pem, keytool -importcert в cacerts. Заработавший браузер про них не говорит ничего.

Кнопки «Всё равно перейти» нет. Значит, на сайте HSTS: он в списке preload или прислал Strict-Transport-Security при прошлом визите. Кнопки нет по замыслу, а не по недосмотру: RFC 6797, пункт 12.1 называется «No User Recourse» и запрещает браузеру её предлагать. Установите сертификат.

Как увидеть это у себя

Отладочный прокси показывает свой корневой сертификат и выгружает его одной кнопкой, с чего установка и начинается. Дальше виден весь обмен: запрос, ответ и тело. Пока сертификат не установлен, видно только начало TLS-рукопожатия и обрыв, тот же признак, что на телефоне. Куда сертификат попадает на каждой платформе: Установка сертификата.