Когда вы вводите в браузер https://example.com, происходит невидимая магия. Браузер не просто подключается к серверу — он проверяет цепочку доверия, убеждаясь, что сертификат сайта подписан авторитетным центром сертификации. Эта цепочка состоит из нескольких сертификатов, каждый из которых подписывает другой. И если где-то в этой цепочке есть разрыв, вы видите красный экран ошибки.
Большинство инженеров понимают "SSL нужен для HTTPS". Но как вообще работает проверка сертификата? Почему иногда браузер говорит "certificate not trusted", хотя сертификат абсолютно валидный? И что это за intermediate certificate, который нужно добавить на сервер? Разберём по шагам.
TLS handshake: начало доверия
Когда браузер инициирует HTTPS-соединение, происходит вот что:
1. Браузер отправляет ClientHello с поддерживаемыми версиями TLS и шифрами. Сервер отвечает ServerHello, выбирая версию и шифр.
2. Сервер отправляет свой сертификат (обычно вместе с цепочкой промежуточных сертификатов). This критический момент: сервер должен отправить не просто leaf certificate, а весь путь до trusted root.
3. Браузер проверяет цепочку: начиная с leaf сертификата, идёт вверх до root certificate, который есть в его trust store. Каждый сертификат подписан предыдущим, создавая неразрывную цепь криптографической проверки.
4. Если цепочка валидна и root certificate присутствует в браузере — соединение устанавливается. Если цепочка сломана или root неизвестен — появляется "SEC_ERROR_UNKNOWN_ISSUER" или аналогичная ошибка.
Цепь доверия: root CA, intermediate, leaf
SSL/TLS использует иерархическую модель доверия:
Root CA (корневой центр сертификации) — это верхушка пирамиды. GlobalSign, DigiCert, Let's Encrypt Trusted Root — это root authorities, чьи сертификаты встроены в каждый браузер, операционную систему, мобильный телефон. Root CA само себя подписывает (самоподписанный сертификат). Его private key хранится в защищённом хранилище, почти никогда не используется для прямого подписания конечных сертификатов.
Intermediate CA (промежуточный центр) — это сертификат, подписанный root. Intermediate может подписывать другие сертификаты. This позволяет root CA оставаться offline, снижая риск компрометации. Intermediate сертификаты должны быть отправлены с вашим server certificate.
Leaf certificate (конечный сертификат) — это ваш сертификат, привязанный к домену. Он подписан intermediate, и содержит ваши публичные ключи для шифрования. Браузер проверяет этот сертификат в первую очередь.
Example цепочки для example.com:
example.com (Leaf Certificate)
↓ Signed by
Intermediate CA Certificate
↓ Signed by
Root CA Certificate (встроен в браузер)Браузер поверхностно смотрит на leaf — но настоящую проверку делает он: валиден ли подпись leaf? Подпись выполнена с помощью private key intermediate? Валиден ли intermediate? Он подписан root? Root присутствует в trust store браузера? Только если все ответы "да", соединение безопасно.
Почему intermediate certificate хранится offline
Можно представить модель, где root CA напрямую подписывает все конечные сертификаты. Но это был бы кошмар:
1. Root CA должна быть онлайн 24/7, готовая подписывать новые сертификаты. Чем больше online-операций — тем выше риск компрометации.
2. Если root key скомпрометирована — вся инфраструктура доверия рушится. Все браузеры будут доверять поддельным сертификатам, пока не обновятся с новым root.
3. Масштабирование усложняется. Root CA должна выполнять миллионы операций подписания ежедневно.
Поэтому используются intermediate certificates. Root CA остаётся в холодном хранилище (air-gapped vault), подписывает intermediate раз в несколько лет. Intermediate онлайн и подписывает миллионы конечных сертификатов. Если intermediate скомпрометирована, её можно отозвать (revoke) и выпустить новую, не трогая root.
Types of Certificates: DV, OV, EV
Есть три основных вида SSL сертификатов. Различаются они уровнем проверки перед выпуском:
DV (Domain Validation) — центр сертификации проверяет только, что вы владеете доменом. Обычно через DNS TXT запись или файл на веб-сервере. Выпускается за минуты. Стоит дёшево или бесплатно (Let's Encrypt, Certbot). С точки зрения HTTPS-шифрования DV полностью функционален — данные шифруются идентично. Различие в trust signaling: браузер не гарантирует, что за доменом стоит конкретная компания, только что кто-то владеет доменом.
OV (Organization Validation) — центр проверяет легальное существование организации: регистрация компании, адрес, контакты. Выпускается 1-7 дней. В старых браузерах отображался синий текст с названием организации. Дороже DV (15-100 USD/год). Often используется в корпоративных сайтах, где важно показать "это реальная компания".
EV (Extended Validation) — самая строгая проверка. Включает финансовый аудит, проверку регистраций, юридическое подтверждение. В старых браузерах EV сертификаты показывались зелёной полосой в адресной строке. Выпускается 10-30 дней. Самый дорогой (100-200+ USD/год). Минус: в современных браузерах (Chrome 77+) EV-индикатор исчез, так как юзеры не различают DV и EV визуально. Плюс: всё ещё используется для высокотехнологичного phishing protection и внутренних систем.
Важный момент: DV, OV, EV используют одну и ту же криптографию. Разница только в процессе выпуска и доверии к организации. Для 99% веб-сайтов DV достаточно.
How Browser Validates the Chain
Процесс валидации сертификата — это классический граф-парсинг:
1. Получение цепочки. Браузер получает сертификат от сервера. Если промежуточные сертификаты не отправлены явно, браузер пытается их найти через Authority Info Access (AIA) запросы к OCSP responder или fetch по URL в сертификате. Мобильные клиенты часто не могут делать эти запросы, поэтому неполная цепь = ошибка.
2. Валидация leaf certificate. Браузер проверяет: сертификат не истёк? Домен в CN или Subject Alternative Names совпадает с запрошенным URL? Подпись вычислена правильно с public key из issuer сертификата (промежуточного)?
3. Построение цепи до root. Затем браузер проверяет intermediate: его подпись валидна? Он подписан root? Промежуточный certificate не истёк? Нет ли revocation status в CRL или OCSP?
4. Проверка root. Браузер ищет root сертификат в своём trust store. Если найден — цепь валидна. Если нет — error "unknown issuer" или "self-signed certificate".
5. Дополнительные проверки. Браузер проверяет Certificate Transparency (CT) logs — каждый публичный сертификат должен быть залогирован в нескольких CT logs для аудитуемости. Старые браузеры пропускают это, новые требуют.
Типичные ошибки SSL и что их вызывает
ERR_SSL_PROTOCOL_ERROR — сервер не отправляет валидные данные TLS. Often: неправильная конфигурация nginx/Apache, SSL отключен на порте 443, или порт прослушивает non-SSL приложение.
SEC_ERROR_UNKNOWN_ISSUER или CERTIFICATE_VERIFY_FAILED — неполная цепь. Сервер отправил только leaf сертификат без intermediate. Браузер не может найти intermediate и объявляет "issuer unknown". Solution: добавить intermediate сертификат в конфигурацию веб-сервера.
NET::ERR_CERT_AUTHORITY_INVALID — root сертификат не в trust store браузера. Случается с самоподписанными сертификатами или самодельными CA. Браузеры не доверяют им без явного добавления в исключения.
SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED — сертификат подписан с помощью устаревшего алгоритма (SHA-1, MD5). Современные браузеры отклоняют такие сертификаты. Нужно перевыпустить с SHA-256.
NET::ERR_CERT_COMMON_NAME_INVALID — домен не совпадает с CN или SAN в сертификате. Например, сертификат для api.example.com, а вы обращаетесь к www.example.com. Solution: использовать wildcard сертификат (*.example.com) или multi-domain сертификат (SAN).
NET::ERR_CERT_VALIDITY_TOO_LONG — браузеры отклоняют сертификаты с validity периодом более 13 месяцев (введено в 2020). Let's Encrypt выпускает на 90 дней, коммерческие CAs часто на 12 месяцев. Если вы видите эту ошибку — перевыпустите.
Как проверить свою SSL цепь
Команда openssl показывает точный состав цепочки:
openssl s_client -connect example.com:443 -showcertsВ выводе вы увидите несколько сертификатов, разделённых "-----BEGIN CERTIFICATE-----". Каждый — часть цепочки. Считаете их число:
- 2 сертификата (leaf + intermediate) = минимально приемлемо
- 3 сертификата (leaf + 2 intermediates) = нормально для коммерческих CAs
- 4+ сертификата = редко, обычно означает старые промежуточные цепочки
Но есть способ удобнее. Откройте /tools/ssl-checker — введите доменем и увидите:
- Полная цепочка сертификатов в браузере
- Детали каждого: кому выпущен, кем подписан, дата выпуска и истечения
- Признаки проблем: неполная цепь, истёкший сертификат, неправильный домен
Let's Encrypt и автоматическое управление сертификатами
Let's Encrypt революционизировал SSL, сделав сертификаты бесплатными и автоматизированными. Вместо того чтобы вручную заказывать сертификаты каждый год, вы запускаете Certbot:
Начальный выпуск. Certbot доказывает Let's Encrypt, что вы владеете доменом (через DNS TXT запись или HTTP file placement). Let's Encrypt выпускает сертификат на 90 дней вместе с цепочкой промежуточных.
Автоматическое продление. За 30 дней до истечения Certbot пытается продлить сертификат. Если это удаётся — новый сертификат готов, веб-сервер перезагружается с новыми файлами, и вы не замечаете ничего.
Что может сломаться. DNS-вызовы не проходят из-за firewall правил. ACME client не может подключиться к Let's Encrypt API. Cron job для renewal отключен. Веб-сервер не перезагружается после renewal. В этих случаях сертификат молча истекает, пока вы не заметите ошибку в браузере.
SSL мониторинг: почему это критично
Сертификаты молча истекают. This не ошибка базы данных, которая вызывает immediate alarm. This ожидаемое событие, которое вы можете забыть. И вот что происходит:
День 1 (истечение). Сертификат истекает ровно в полночь. Ваш веб-сервер продолжает работать, браузер продолжает подключаться (иногда со скрытым warning). Вы ничего не замечаете.
День 3. Мобильные приложения начинают отклонять соединение. Клиенты жалуются, что приложение "упало". Слэк взрывается. Вы берёте laptop и открываете браузер — работает! This шизофренично.
День 5. Curl не подключается. API клиенты падают. Вы наконец замечаете, что сертификат истёк. Теперь нужно срочно его переодолжить или перегенерировать.
День 7. Истекшему сертификату не доверяет 40% корпоративных firewall-ов. У вас 3 часа простоя для некоторых регионов, пока вы обновляете сертификат и браузеры кэшируют новый.
SSL мониторинг работает просто: ежедневно проверяется certificate expiry дата. Если до истечения остаётся менее 30 дней — отправляется алерт. Уведомление приходит в email, Slack, Telegram — за месяц до проблемы вы знаете, что нужно действовать.
SSL expiry alerts в AtomPing настраиваются per-target. Например, для критичного API — alert за 45 дней. Для staging — за 7 дней. И система проверяет все ваши сертификаты параллельно, поэтому вы никогда не пропустите истечение, даже если у вас 300 доменов.
CAA записи и привязка сертификатов
CAA (Certification Authority Authorization) — это DNS запись, которая говорит: "эту доменy разрешено выпускать сертификаты только этим CA". This дополнительный слой безопасности против компрометации.
Example CAA записи:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"This говорит: "Let's Encrypt, только ты можешь выпускать сертификаты для example.com". Если какой-то другой CA попытается выпустить сертификат для вашего домена, Let's Encrypt проверит CAA запись, увидит "не ты" и откажет.
CAA особенно важен для коммерческих CAs, которые используют более слабую валидацию домена. С CAA вы гарантируете, что сертификат может быть выпущен только авторизованным CA, даже если attacker скомпрометировал DNS вашего домена.
Подробнее о DNS и CAA читайте в нашей статье о DNS records.
Как исправить неполную цепь
Если у вас "unknown issuer" ошибка:
1. Получите промежуточный сертификат. Ваш CA (DigiCert, Sectigo, Let's Encrypt) обычно предоставляет его на сайте в разделе "downloads" или "intermediate certificate". Let's Encrypt сертификаты часто идут с intermediate embedded при выпуске.
2. Объедините сертификаты в одном файле. Порядок критичен: сначала ваш leaf (domain.crt), затем intermediate(s), затем (опционально) root. Файл обычно называется chain.pem или fullchain.pem.
3. Обновите конфигурацию веб-сервера. Для nginx: ssl_certificate указывает на fullchain.pem (содержит leaf + intermediates), ssl_certificate_key указывает на private key. Для Apache: SSLCertificateFile = leaf, SSLCertificateChainFile = intermediates.
4. Перезагрузите сервер. Без перезагрузки новые сертификаты не вступят в силу.
5. Проверьте цепь. Используйте openssl s_client или SSL Checker, чтобы убедиться, что цепь теперь полная и браузер не видит ошибок.
Сравнение типов сертификатов
| Тип | Validation Уровень | Время выпуска | Стоимость | Usage |
|---|---|---|---|---|
| DV | Домен | Минуты | Бесплатно - $10 | Большинство веб-сайтов |
| OV | Организация | 1-7 дней | $20-100 | Корпоративные сайты |
| EV | Extended | 10-30 дней | $100-200+ | Финансовые, высокий trust |
SSL цепь и мониторинг: практический чек-лист
1. Проверьте, что ваш сервер отправляет полную цепь. Используйте openssl s_client -showcerts или SSL Checker. Вы должны видеть минимум 2 сертификата (leaf + intermediate).
2. Убедитесь, что промежуточный сертификат добавлен в конфигурацию веб-сервера. Для nginx это обычно ssl_certificate file (fullchain.pem), для Apache это SSLCertificateChainFile.
3. Включите SSL мониторинг для всех критичных доменов. Проверяйте certificate expiry каждый день, получайте алерты за 30 дней до истечения. SSL expiry alerts — встроены во все планы AtomPing.
4. Настройте автоматическое продление. Для Let's Encrypt используйте Certbot с cron job для ежемесячной попытки renewal. Для коммерческих CAs — установите напоминание за 45 дней в календаре.
5. Добавьте CAA записи для вашего домена. Укажите, какой CA может выпускать сертификаты. This защитит от unauthorized certificate issuance.
6. Используйте современные алгоритмы. SHA-256 или выше. Избегайте SHA-1, MD5, которые браузеры отклоняют.
7. Тестируйте на мобильных устройствах. Старые версии iOS, Android иногда не могут загружать intermediate сертификаты через AIA. Неполная цепь может пройти на desktop, но упасть на мобиле.
Conclusion: доверие базируется на цепочке
SSL certificate chain — это основа интернета. Каждый раз, когда вы вводите https://example.com, браузер выполняет криптографическую проверку цепочки, убеждаясь, что сервер — тот, за кого себя выдаёт. Если в этой цепочке есть разрыв (неполная цепь, истёкший сертификат, неправильный домен), соединение отклоняется.
Как инженер, вам нужно знать:
1. Цепь состоит из leaf (ваш сертификат) → intermediates → root (в браузере). Сервер должен отправлять всю цепь, не полагаясь на браузер fetch промежуточных.
2. Типов три: DV (быстро, бесплатно), OV (медленнее, проверяет организацию), EV (самая строгая). Для большинства DV достаточно.
3. Let's Encrypt упростил SSL, но автоматическое продление может сломаться. Мониторинг за 30 дней до истечения — минимум страховки.
4. Типичные ошибки: неполная цепь (unknown issuer), истёкший сертификат, неправильный домен. Все решаются за минуты, если вы знаете, что искать.
Проверьте ваш SSL сертификат прямо сейчас на /tools/ssl-checker — введите домен и увидите всю цепочку, даты, и потенциальные проблемы. И включите SSL мониторинг для вас доменов, чтобы никогда не пропустить истечение.
Связанные материалы
SSL Checker — проверьте свой SSL сертификат и цепь онлайн. Видите полную цепочку, даты выпуска/истечения, и типичные проблемы.
DNS Record Types Explained — узнайте о CAA записях, которые привязывают сертификаты к доменам.
SSL Expiry Alerts — настройте автоматические уведомления за 30 дней до истечения сертификата. Never больше не пропустите certificate renewal.
FAQ
What is an SSL certificate chain?
An SSL certificate chain is a sequence of certificates that establish trust from your website's certificate to a Certificate Authority that browsers recognize. The chain typically includes: a leaf certificate (your website), one or more intermediate certificates, and a root certificate. Browsers validate the entire chain to confirm your certificate is legitimate.
Why do intermediate certificates exist?
Root CA private keys are kept offline in secure vaults for security reasons. Intermediate certificates act as signing authorities, allowing CAs to issue end-entity certificates without exposing the root key. If an intermediate certificate is compromised, the CA can revoke it without affecting the root — but if the root key is compromised, the entire trust system is broken.
What does 'incomplete chain' mean?
An incomplete chain occurs when your server sends only the leaf certificate without the intermediate certificate(s). Browsers usually can fetch the missing intermediate, but some mobile clients and older devices cannot. This causes SSL errors even though your certificate is valid. Always configure your server to send the complete chain.
How can I check if my SSL chain is complete?
Use 'openssl s_client -connect example.com:443' from the command line. Count the number of certificates in the output — you should see at least 2 (leaf + intermediate). Or use an online tool like AtomPing's SSL Checker at /tools/ssl-checker to instantly view your complete chain and identify any issues.
What's the difference between DV, OV, and EV certificates?
DV (Domain Validated) certificates only verify you own the domain — cheapest and fastest. OV (Organization Validated) certificates verify your organization's legal existence — shown in certificate details. EV (Extended Validation) certificates perform the strictest validation and trigger a green bar in old browsers (deprecated in modern browsers). For HTTPS security, all three provide identical encryption — the difference is trust signaling.
Why did my SSL certificate expire if I set up auto-renewal?
Let's Encrypt certificates are valid for 90 days and require renewal before expiry. If auto-renewal failed (due to DNS issues, firewall blocking ACME requests, or cron misconfiguration), your certificate expires without replacement. This is why SSL expiry monitoring is critical — AtomPing monitors certificates and alerts 30 days before expiry, giving you time to fix renewal issues.