Root CA

Root CA (Root Certificate Authority, корневой центр сертификации) — организация, чей самоподписанный X.509-сертификат встроен напрямую в хранилище доверенных сертификатов операционных систем (Windows Trust Store, macOS Keychain, NSS в Firefox/Linux) или браузеров. Root CA — вершина иерархии Public Key Infrastructure (PKI) и единственное, чему клиент доверяет «по умолчанию» без дополнительной проверки.

Иерархия PKI

Типичная трёхуровневая цепочка:

1. Root CA — корневой сертификат, самоподписанный, хранится офлайн (HSM-устройства в физически защищённых помещениях).
2. Intermediate CA (промежуточный CA) — подписан Root CA, используется для подписи конечных сертификатов. Серверы HTTPS должны включать цепочку промежуточных CA в свой TLS-ответ.
3. End-entity certificate — сертификат домена, подписанный промежуточным CA.

Браузер проверяет: является ли Root CA доверенным (есть ли он в Trust Store), непрерывна ли цепочка подписей, не истёк ли срок действия каждого сертификата, не отозван ли сертификат (OCSP).

Крупнейшие Root CA (по объёму выданных сертификатов, данные 2024): DigiCert, IdenTrust (Let's Encrypt использует кросс-подпись через IdenTrust DST Root CA X3, затем перешёл на ISRG Root X1), Sectigo, GlobalSign, Amazon Trust Services, Google Trust Services.

Root CA и безопасность

Root CA никогда не используется для подписи конечных сертификатов напрямую — всегда через промежуточные CA. Причина: если Root CA скомпрометирован, все выданные им сертификаты теряют доверие, а операционные системы должны выпускать обновления. Промежуточный CA можно отозвать (CRL, OCSP) без затрагивания Root. Ключ Root CA хранится на HSM (Hardware Security Module) в строго контролируемых условиях — нередко в физически раздельных дата-центрах.

CAB Forum (Certification Authority/Browser Forum) устанавливает базовые требования к Root CA и их политикам выпуска сертификатов. Все Root CA в Mozilla NSS или Windows Root Certificate Program обязаны соответствовать этим требованиям и проходить ежегодный аудит (WebTrust или ETSI EN 319 411).

История

PKI для интернета возникла в середине 1990-х. VeriSign стал первым крупным публичным CA и одним из первых Root CA, включённых в браузеры Netscape (1995). Скандал с Comodo (2011) и DigiNotar (2011, взлом с выпуском поддельных сертификатов Google, Firefox) показал уязвимость системы и ускорил внедрение Certificate Transparency (CT) логов — публичных журналов всех выданных сертификатов.

На что обращать внимание

Настройка HTTPS на сервере требует корректной цепочки: сертификат домена + промежуточные CA. Если промежуточный CA не включён в ответ сервера — браузер попытается загрузить его по AIA (Authority Information Access), что добавляет задержку. В nginx: директива ssl_certificate должна содержать файл с полной цепочкой (fullchain.pem). Использование самоподписанного сертификата не имеет Root CA в Trust Store браузеров — это вызывает предупреждение. Для внутренних систем нужен либо корпоративный Root CA (добавленный в Trust Store через GPO/MDM), либо публичный сертификат.

История корневых УЦ

Система PKI (Public Key Infrastructure) с корневыми УЦ разработана в 1990-х годах. Первый коммерческий Root CA — VeriSign Class 1 (1995). Программы доверия Mozilla Root Program (2001) и Microsoft Root Certificate Program (2002) определяют, каким корневым УЦ доверяют браузеры. К 2023 году в Mozilla Trust Store около 140 корневых сертификатов. Получить включение в Trust Store — процесс длиной 1–3 года с аудитами WebTrust.

Типичные проблемы с Root CA

Самая частая проблема — неполная цепочка сертификатов на сервере: отсутствует промежуточный Intermediate CA. Браузер не может построить путь доверия до Root CA. Проверьте командой openssl s_client -connect domain.com:443: в разделе Certificate chain должны быть все звенья. Инструмент SSL Labs (ssllabs.com/ssltest) визуально показывает цепочку.