Цепочка доверия (chain of trust) строится по принципу: конечный сертификат подписан промежуточным CA, который подписан корневым CA. Корневой CA включён в хранилище доверия браузера или ОС.
Структура цепочки
- Root CA — корневой удостоверяющий центр. Самоподписанный сертификат, зашитый в браузер/ОС. Например: ISRG Root X1 (Let's Encrypt), DigiCert Global Root CA.
- Intermediate CA — промежуточный CA. Подписан Root CA, но хранится не в браузере — его передаёт сервер. Буферный слой: компрометация промежуточного CA не требует отзыва корневого.
- Leaf (End-Entity) Certificate — конечный сертификат сайта. Подписан промежуточным CA.
Проблемы с цепочкой
Типичная ошибка на сервере — отсутствие промежуточного сертификата в конфигурации. Браузер показывает «Ваше соединение не защищено», хотя сертификат технически валиден. В Nginx правильная конфигурация: ssl_certificate должен содержать полную цепочку — сначала конечный, затем промежуточные сертификаты (fullchain.pem у certbot).
Проверка цепочки: openssl s_client -connect example.com:443 -showcerts или онлайн через SSL Labs (ssllabs.com).
История
Модель X.509 PKI (Public Key Infrastructure) с цепочками сертификатов стандартизирована в RFC 5280. SSL-сертификат сайта всегда является leaf-сертификатом в цепочке. Промежуточные CA введены как обязательная практика после инцидентов с компрометацией корневых CA (DigiNotar, 2011). Certificate Transparency (CT, RFC 6962, 2013) позволяет публично проверять всю цепочку.
Как работает цепочка доверия
Цепочка сертификатов (Certificate Chain) — иерархия доверия: Root CA → Intermediate CA → Leaf (сертификат сайта). Root CA — корневой сертификат, встроенный в хранилище доверенных центров браузера/ОС. Intermediate CA — промежуточный, не встроен в браузеры, но подписан Root CA. Leaf — сертификат вашего домена, подписан Intermediate CA.
Браузер проверяет цепочку снизу вверх: example.com cert → подписан Sectigo RSA DV TLS CA → подписан USERTrust RSA CA → подписан AAA Certificate Services (Root, встроен в браузер). Верификация: подпись каждого звена проверяется публичным ключом вышестоящего CA.
Правильная установка цепочки
Сервер должен отдавать клиенту не только сертификат домена, но и все промежуточные CA. Иначе браузер не сможет построить цепочку до Root CA и покажет ошибку «NET::ERR_CERT_AUTHORITY_INVALID». Настройка в Nginx: ssl_certificate /path/to/fullchain.pem; — файл fullchain.pem содержит сертификат домена + все промежуточные CA. Certbot создаёт fullchain.pem автоматически.
Проверить цепочку: openssl s_client -connect example.com:443 -showcerts — покажет все сертификаты в цепочке. Онлайн-инструменты: SSL Labs (ssllabs.com/ssltest/) анализирует цепочку, протокол, cipher suites и выдаёт рейтинг A/B/C.
Cross-signing и альтернативные пути
Сертификат Root CA может быть кросс-подписан другим Root CA — это создаёт альтернативные пути доверия. Let's Encrypt Root CA (ISRG Root X1, 2015) изначально кросс-подписан IdenTrust DST Root CA X3 для обратной совместимости со старыми устройствами. Когда DST Root CA X3 истёк в 2021 году, устройства без ISRG Root X1 (Android < 7.1) потеряли доверие к Let's Encrypt. Именно поэтому Let's Encrypt теперь имеет E1/R3 Intermediate CA подписанные напрямую ISRG Root X1.
OCSP и CRL для проверки отзыва
OCSP (Online Certificate Status Protocol) — протокол проверки отзыва сертификата. Браузер запрашивает OCSP-сервер CA: «не отозван ли этот сертификат?». OCSP Stapling — сервер сам запрашивает OCSP-ответ у CA и прикладывает к TLS handshake, избавляя браузер от отдельного запроса. CRL (Certificate Revocation List) — устаревший метод: публикация списка отозванных сертификатов. Отозванный сертификат должен быть заменён немедленно.