Интернет иногда ломается парадоксально. DNS исправно возвращает IP-адрес, сервер отвечает, порт 443 открыт, но Chrome показывает ERR_CERT_AUTHORITY_INVALID, Firefox выдаёт SEC_ERROR_UNKNOWN_ISSUER, а приложение пишет certificate verify failed. Сервер может быть полностью работоспособен. Клиент просто не нашёл удостоверяющий центр, которому готов доверять.
Корневое хранилище сертификатов, или root store, задаёт исходные точки доверия для HTTPS. Браузер получает сертификат сайта и пытается построить криптографически подтверждённый путь до корневого центра сертификации. Если подходящего доверенного корня нет, идентичность сервера считается неподтверждённой. Именно поэтому изменение нескольких записей в root store способно открыть или закрыть пользователю доступ сразу к тысячам сайтов.
Как браузер решает, кому верить
Упрощённо корневое хранилище можно представить как список удостоверяющих центров, которым разработчик браузера, производитель операционной системы или администратор разрешил выступать якорями доверия. В действительности механизм сложнее. Вместе с сертификатами действуют ограничения, области применения, признаки доверия и недоверия, сроки вывода корней из эксплуатации и дополнительные политики. Такой подход прямо описывают программы доверия Mozilla и Chrome.
Обычная цепочка публичного сайта состоит как минимум из конечного сертификата сайта, промежуточного удостоверяющего центра и корневого центра. Корневой сертификат обычно самоподписан, но самоподпись не создаёт доверия. Браузер доверяет корню потому, что корень уже находится среди разрешённых якорей или был явно добавлен пользователем либо администратором.
Веб-сервер обычно передаёт свой сертификат и нужные промежуточные сертификаты. Передавать корень обычно бессмысленно. Если клиент уже доверяет корню, копия не нужна. Если клиент корню не доверяет, получение того же сертификата от проверяемого сервера доверия не добавит. Такой принцип следует из модели TLS и хорошо виден в документации Let's Encrypt и стандарте TLS 1.3.
Есть ещё одна тонкость. Сертификат не «шифрует интернет» и в современном TLS 1.3 браузер не создаёт готовый сеансовый ключ, чтобы затем зашифровать его открытым RSA-ключом сервера. Клиент и сервер обычно обмениваются эфемерными параметрами Диффи-Хеллмана и независимо получают общий секрет. Сертификат нужен для аутентификации сервера. Сообщение CertificateVerify доказывает владение закрытым ключом и связывает личность сервера с конкретным TLS-рукопожатием. Механизм описан в RFC 8446 и техническом разборе Cloudflare.
После получения цепочки браузер проверяет цифровые подписи, соответствие имени домена, допустимые назначения ключей, срок действия, алгоритмы и ограничения удостоверяющих центров. Для публичных центров браузеры применяют дополнительные правила своих root-программ и требования CA/Browser Forum. Например, для новых публичных TLS-сертификатов максимальный срок действия уже сокращён до 200 дней, затем лимит уменьшится до 100 и 47 дней. График закреплён в решении CA/Browser Forum и подтверждается документацией DigiCert.
Почему один и тот же сайт у разных людей работает по-разному
Главное заблуждение звучит так. У компьютера есть единое системное хранилище, а все программы просто смотрят туда. Современный стек устроен сложнее.
Windows поддерживает системные хранилища уровня компьютера и пользователя, а Microsoft распространяет публичные решения о доверии и недоверии через Certificate Trust Lists. По умолчанию Windows умеет автоматически получать обновлённые списки. Механизм подробно описан в документации Microsoft, а разделение между Local Machine и Current User подтверждается отдельным описанием хранилищ.
Chrome на Windows уже нельзя описывать фразой «использует корни Windows». Chrome Root Store и собственный проверяющий механизм работают на Windows, macOS, Linux, ChromeOS и Android. Chrome при этом учитывает явно добавленные локальные корни, например корпоративный CA в Windows. На iOS Chrome Root Store не используется из-за требований платформы Apple. Подробности опубликованы в Chrome Root Store FAQ, а собственное хранилище Apple описано в Apple Support.
Firefox сохраняет собственную публичную программу Mozilla Root Store, но старое утверждение «Firefox полностью игнорирует сертификаты операционной системы» тоже устарело. Начиная с Firefox 120 браузер умеет автоматически доверять сторонним корням, установленным пользователем или организацией в операционной системе. Функция включена по умолчанию и описана в свежей справке Firefox. При этом публичный набор корней Mozilla по-прежнему регулируется отдельной Root Store Policy.
Android добавляет ещё один уровень путаницы. Начиная с Android 14 системный набор публичных корней можно обновлять через модуль Conscrypt, не дожидаясь полного обновления ОС. Но пользовательский CA и системный CA для приложений не равнозначны. Приложения, рассчитанные на Android 7.0 и новее, по умолчанию не обязаны доверять сертификатам, которые пользователь вручную добавил в пользовательское хранилище. Разработчик должен разрешить такое доверие через Network Security Configuration. Правило описывают Android Developers и проект AOSP.
Поэтому после ручной установки корпоративного или российского корня сайт может заработать в браузере, а банковское приложение продолжит выдавать ошибку TLS. Приложение может использовать собственный набор CA, собственную сетевую библиотеку или certificate pinning. Аналогичная проблема встречается в Java, Python, контейнерах и серверных программах. Системный root store не гарантирует, что конкретный процесс вообще к нему обращается.
Есть и обратная ситуация. Сервер забывает передать промежуточный сертификат. Один компьютер всё равно открывает сайт, потому что нужный intermediate уже находится в кэше или клиент смог получить его через AIA. Свежая система или другая библиотека получает ту же конечную запись и падает с ошибкой неизвестного издателя. В тестах Chromium отсутствие промежуточного сертификата прямо приводит к ERR_CERT_AUTHORITY_INVALID, если получить intermediate другим способом не удаётся. Let's Encrypt поэтому рекомендует серверу передавать полную необходимую цепочку промежуточных сертификатов.
История уже показывала масштаб подобных зависимостей. После истечения старого AddTrust External CA Root современные клиенты смогли построить путь к новому корню USERTrust, а часть старых OpenSSL-систем и устаревших устройств потеряла доступ к сервисам. Поведение подробно разобрали Red Hat и сам Sectigo. Похожий переход произошёл у Let's Encrypt при завершении эпохи DST Root CA X3. Проблема была не в том, что «сломался HTTPS», а в том, что разные клиенты умели строить разные пути доверия.
Российские сертификаты сделали root store заметным обычному пользователю
Для России вопрос перестал быть чисто технической экзотикой. Национальный удостоверяющий центр Минцифры выпускает TLS-цепочки, которые ведут к российским корням. Если нужного корня нет среди доверенных для конкретного клиента, пользователь получает ERR_CERT_AUTHORITY_INVALID, SEC_ERROR_UNKNOWN_ISSUER или аналогичную ошибку. Официальная точка распространения сертификатов находится на Госуслугах, актуальную практику установки и проверки также подробно разбирает SecurityLab.
Нынешний комплект уже сложнее первоначальной пары файлов. Помимо RSA-цепочки распространяются дополнительные выпускающие сертификаты и сертификаты на российских криптографических алгоритмах. Состав набора меняется, поэтому скачивать случайный файл с привычным названием из старой статьи или облачного хранилища я бы не стал. Актуальный комплект нужно брать с Госуслуг. Текущую структуру файлов подтверждают свежие инструкции SecurityLab для Linux и рекомендации Московской биржи.
Установка российского корня не добавляет браузеру поддержку ГОСТ TLS сама по себе. Обычный Russian Trusted Root CA и поддержка криптографических алгоритмов являются разными уровнями системы. Если сервис требует именно ГОСТ TLS, понадобится совместимый криптографический стек или специализированный браузер. Разница разобрана в материале SecurityLab о macOS и в обзоре Chromium GOST.
Другой распространённый миф звучит страшнее. «Установил государственный или корпоративный корень, теперь владелец центра автоматически читает весь HTTPS». Одного корневого сертификата для расшифровки трафика недостаточно. У атакующей или инспектирующей стороны должен появиться сертификат для нужного домена и возможность поставить себя в путь соединения, например через прокси, контролируемую сеть, DNS или устройство пользователя.
Но дополнительный корень действительно расширяет круг субъектов, сертификатам которых клиент готов доверять. Корпоративные системы TLS inspection работают именно по такой модели. Прокси устанавливает отдельное TLS-соединение с настоящим сайтом, расшифровывает трафик и создаёт второе TLS-соединение с пользователем, предъявляя сертификат, подписанный корпоративным CA. Механизм наглядно описывает Microsoft, а Mozilla отдельно предупреждает, что программы, инспектирующие HTTPS, могут вмешиваться в защищённые соединения и вызывать ошибки Firefox.
Поэтому корневой сертификат нельзя воспринимать как обычный файл настроек. Устанавливать случайный CA из Telegram, письма, форума или неизвестного архива опасно. Имя файла ничего не доказывает. Поддельный сертификат можно назвать Russian Trusted Root CA.cer или Company Security Root.cer. Проверять нужно источник, субъект, издателя и отпечаток.
Материал предназначен для легальной диагностики собственных устройств и информационных систем. При работе с корневыми сертификатами, TLS-инспекцией и корпоративными центрами сертификации соблюдайте законодательство своей страны, включая законодательство России. Не применяйте такие механизмы для несанкционированного перехвата трафика, слежки, взлома или доступа к чужим данным.
Как понять, почему сайт не открывается
На Windows сначала полезно посмотреть реальные доверенные корни. Хранилище компьютера открывается командой certlm.msc, хранилище текущего пользователя командой certmgr.msc. Разницу между ними описывает Microsoft. В Chrome начиная с версии 134 доступен общий менеджер сертификатов, что подтверждает документация Chromium.
chrome://certificate-managerВ PowerShell список доверенных корней компьютера можно получить без графического интерфейса.
Get-ChildItem Cert:LocalMachineRoot |
Select-Object Subject, Issuer, Thumbprint, NotAfter
Сам сервер я обычно начинаю проверять через OpenSSL. Параметр -servername передаёт SNI, без него сервер с несколькими сайтами способен вернуть вообще другой сертификат.
openssl s_client
-connect example.com:443
-servername example.com
-showcerts
-verify_return_errorДиагностику удобно строить не вокруг слова «сертификат», а вокруг конкретной ошибки.
| Симптом | Что проверять первым |
|---|---|
ERR_CERT_AUTHORITY_INVALID
|
Доверенный корень, промежуточные сертификаты, локальный CA, TLS-инспекцию |
SEC_ERROR_UNKNOWN_ISSUER
|
Цепочку до корня и наличие промежуточного сертификата |
| Сертификат истёк | Срок конечного сертификата и часы устройства |
| Имя сертификата не совпадает | SNI, SAN, настройки виртуального хоста и прокси |
| Работает в браузере, не работает в приложении | Собственное хранилище приложения, Android Network Security Config, pinning |
| Работает на старом компьютере, не работает на новом | Кэш промежуточных CA, локально добавленные корни и различия root store |
Я бы не лечил сертификатные ошибки командами curl -k, --insecure или запуском браузера с отключённой проверкой сертификатов. Такие параметры не добавляют правильный корень, а убирают проверку личности сервера. Ошибка исчезает вместе с защитой, которая должна была предупредить о подмене.
И ещё один принципиальный момент. Нормальная цепочка TLS не доказывает, что сайт честный. Бесплатный публичный сертификат может получить и владелец фишингового домена. HTTPS сообщает другое. Клиент установил защищённое соединение с сервером, который доказал владение ключом для указанного домена, а цепочка сертификатов удовлетворила правилам доверия клиента. Репутацию владельца, законность бизнеса и отсутствие вредоносного содержимого root store не проверяет.
Что такое корневое хранилище сертификатов простыми словами?
Корневое хранилище содержит сертификаты и правила доверия для удостоверяющих центров, которые могут завершать цепочку проверки HTTPS. Если клиент не находит подходящий доверенный корень, сайт получает ошибку сертификата даже при исправном сервере и сети.
Почему корневой сертификат самоподписан?
Корень находится на вершине конкретной иерархии и не нуждается в подписи вышестоящего CA. Самоподпись не создаёт доверия. Решение доверять корню принимает браузер, производитель ОС, пользователь или администратор.
Передаёт ли сайт корневой сертификат браузеру?
Обычно нет необходимости. Сервер передаёт конечный сертификат и нужные промежуточные сертификаты. Корневой сертификат уже должен быть известен клиенту как доверенный якорь. Переданный сервером неизвестный корень сам по себе доверенным не становится.
Почему сайт открывается в Chrome, но не работает в приложении?
Приложение может использовать отдельный набор доверенных CA, собственную TLS-библиотеку или certificate pinning. Особенно часто такая разница встречается на Android, в Java, Python, контейнерах и корпоративном программном обеспечении.
Опасно ли устанавливать дополнительный корневой сертификат?
Дополнительный корень расширяет область доверия клиента. Сам файл не позволяет владельцу CA автоматически расшифровать весь HTTPS, но при наличии подходящего сертификата и контроля сетевого пути доверенный CA может участвовать в TLS-инспекции. Поэтому источник корня нужно проверять особенно тщательно.
Может ли один корневой сертификат сломать доступ сразу ко многим сайтам?
Да. Большое количество промежуточных центров и конечных сертификатов может строить цепочку к одному корню. Истечение срока корня, его удаление из root store или изменение правил доверия способно затронуть множество сайтов и программ одновременно, особенно на старых клиентах.
Корневое хранилище я бы сравнил не с телефонной книгой, а со списком тех, чью подпись система принимает без дополнительного поручителя. DNS говорит браузеру, куда идти. TLS защищает канал. Сертификат связывает домен с криптографическим ключом. Root store решает, чьё подтверждение этой связи клиент вообще готов считать достаточным. Поэтому живой сервер с правильным IP и исправным HTTPS способен в один момент стать недоступным для конкретной группы устройств, если у группы исчез подходящий путь до доверенного корня.
