Цепочка сертификатов SSL: порядок, проверка, ошибки

Что такое цепочка сертификатов SSL?

Цепочка сертификатов SSL (также называемая цепочкой доверия или путём сертификации) — это упорядоченный список цифровых сертификатов, который связывает SSL/TLS-сертификат вашего сайта с доверенным корневым Центром сертификации (CA). Каждый сертификат в цепочке подписан цифровой подписью вышестоящего сертификата, создавая проверяемый путь доверия от вашего сервера до корневого CA, которому браузеры уже доверяют.

Представьте это как цепочку поручительств. Сертификат сервера говорит: «Я — example.com». Промежуточный CA говорит: «Я ручаюсь за сертификат example.com». Корневой CA говорит: «Я ручаюсь за этот промежуточный». Ваш браузер уже доверяет корневому CA, поэтому, следуя цепочке подписей, он доверяет и вашему серверу.

Когда вы открываете HTTPS-сайт, браузер проходит эту цепочку за миллисекунды. Если каждое звено в порядке, страница загружается без предупреждений. Если какое-либо звено отсутствует, просрочено или не вызывает доверия, вместо страницы вы видите предупреждение безопасности, например NET::ERR_CERT_AUTHORITY_INVALID.

Три вида сертификатов в цепочке

В каждой цепочке есть три вида сертификатов, хотя сервер может отправлять несколько промежуточных:

Корневой сертификат

Корневой сертификат — это якорь доверия на вершине цепочки. Он самоподписанный: Центр сертификации подписал собственный сертификат. Корневые сертификаты предустановлены в браузере и операционной системе — этот набор называется хранилищем доверенных сертификатов.

В собственном списке Chrome около 100 корневых сертификатов (Chrome Root Store); у Mozilla, Apple и Microsoft свои списки. Корневые сертификаты выпускают такие организации, как DigiCert, Let's Encrypt (ISRG), Sectigo, GlobalSign и Google Trust Services. Поскольку корневые ключи очень ценны, CA хранят их офлайн в аппаратных модулях безопасности и используют только для подписания промежуточных сертификатов.

Промежуточный сертификат

Промежуточные сертификаты находятся между корневым и сертификатом вашего сервера. Корневой CA подписывает промежуточный сертификат, а промежуточный CA затем подписывает конечные (серверные) сертификаты. Большинство CA используют один-два промежуточных.

Ваш веб-сервер должен отправлять промежуточные сертификаты вместе с leaf-сертификатом во время TLS-рукопожатия. Chrome умеет скачивать недостающий промежуточный сертификат, а Firefox заранее хранит их, но у приложений, API-клиентов и старых устройств Android нет ни того, ни другого, поэтому для них цепочка рвётся.

Leaf-сертификат (серверный сертификат)

Leaf-сертификат (также называемый сертификатом конечной сущности или серверным сертификатом) — это сертификат, установленный на вашем веб-сервере. Он содержит имя домена, открытый ключ, срок действия и информацию об издателе (промежуточном CA, который его подписал).

Это первый сертификат, который браузер получает во время TLS-рукопожатия. Затем браузер поднимается по цепочке, проверяя каждую подпись, пока не достигнет доверенного корневого сертификата.

Как работает цепочка доверия

Когда браузер подключается к сайту по HTTPS, TLS-рукопожатие запускает процесс проверки цепочки, который происходит за миллисекунды:

• Сервер отправляет свои сертификаты — сначала leaf, затем промежуточные.
• Браузер строит путь — от leaf вверх до корневого сертификата из собственного списка. Если промежуточного сертификата нет, Chrome скачивает его по адресу, указанному в сертификате (AIA), а Firefox использует собственный предустановленный набор; многие другие клиенты просто выдают ошибку.
• Проверяются подписи — каждый сертификат должен быть подписан ключом вышестоящего.
• Проверяется корневой сертификат — путь должен заканчиваться корневым сертификатом из списка браузера. Неизвестный корневой сертификат не проходит проверку.
• Проверяется срок действия — каждый сертификат должен быть в пределах своих дат и не отозван, а leaf должен покрывать имя в адресной строке.

Реальные цепочки: что отправляют 12 крупных сайтов

27 октября 2026 года мы запросили цепочки у 12 крупнейших сайтов (openssl s_client -showcerts, из двух мест). Ни один не отправил только leaf, а несколько добавили перекрёстно подписанные сертификаты, чтобы старые устройства всё же дошли до известного им корневого. То, что отправляет сервер, может меняться в зависимости от версии TLS, поддержки ECDSA в клиенте и от того, какой узел CDN отвечает: например, facebook.com по TLS 1.2 отправил 3 сертификата.

Что происходит после проверки

Если все проверки пройдены, соединение устанавливается. Если не прошла хотя бы одна, даже по промежуточному сертификату, браузер показывает предупреждение вроде «Ваше подключение не защищено» с кодом, например NET::ERR_CERT_AUTHORITY_INVALID. (Сбои до того, как какой-либо сертификат вообще проверяется, прямо во время TLS-рукопожатия, дают другие коды: ERR_SSL_PROTOCOL_ERROR или ERR_SSL_VERSION_OR_CIPHER_MISMATCH.)

Вот почему важна вся цепочка, а не только leaf-сертификат. Просроченный промежуточный сертификат ломает HTTPS так же, как просроченный серверный, если только клиент не может построить другой путь в обход него.

Почему существуют промежуточные сертификаты

Корневые CA теоретически могли бы подписывать каждый серверный сертификат напрямую, полностью минуя промежуточные. Но есть три критические причины, почему они этого не делают:

• Изоляция безопасности — Закрытые ключи корневого CA хранятся офлайн в HSM внутри физически защищённых хранилищ. Они используются только для подписания промежуточных, а не миллионов отдельных серверных сертификатов. Это резко снижает риск компрометации корневого ключа.
• Ограничение ущерба — Если промежуточный CA скомпрометирован, затрагиваются только сертификаты этого промежуточного. Корневой CA может отозвать скомпрометированный промежуточный и выпустить новый — не аннулируя все когда-либо выданные сертификаты.
• Операционная гибкость — CA используют разные промежуточные для разных целей: один для DV-сертификатов, другой для EV, отдельные для разных регионов или алгоритмов ключей (RSA vs ECDSA).

Как проверить цепочку сертификатов SSL

Существует три способа проверить цепочку сертификатов сайта — от инструментов командной строки до проверок в браузере.

Способ 1: OpenSSL (командная строка)

Команда openssl — самый подробный способ проверки цепочки сертификатов. Выполните это в терминале:

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# Then read the verdict
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -m1 'Verify return code'

Способ 2: просмотр сертификатов в браузере

Каждый крупный браузер показывает построенную им цепочку (она может отличаться от отправленной сервером, если браузер сам скачал недостающий промежуточный сертификат):

• Chrome: нажмите значок слева от адреса → Подключение защищено → Действительный сертификат, затем откройте вкладку Подробнее, чтобы увидеть иерархию сертификатов
• Edge: нажмите значок замка → "Connection is secure" → значок сертификата в верхней части панели
• Firefox: нажмите значок замка → "Connection secure" → "More information" → "View Certificate"; у каждого сертификата цепочки своя вкладка
• Safari (18.4 и новее): выберите в строке меню «Safari» > «Сведения о безопасности подключения» (Apple); на iPhone нажмите левую часть адресной строки → "Privacy & Security" → "Connection Security Details"

Способ 3: SSL-проверка DNS Robot

Самая быстрая проверка снаружи вашей сети — наша SSL-проверка: она показывает цепочку, которую отправляет сервер, доверяют ли ей списки корневых сертификатов Mozilla, Chrome, Apple и Microsoft, предупреждает о неполной цепочке и показывает даты каждого сертификата. Для сайтов за Cloudflare она читает сертификат из публичных журналов CT, поэтому там цепочка, которую отправляет сервер, не проверяется.

Распространённые ошибки цепочки сертификатов и их исправление

Проблемы с цепочкой сертификатов — одна из самых частых причин ошибок HTTPS. Вот ошибки, с которыми вы скорее всего столкнётесь, и способы их решения.

Отсутствующий промежуточный сертификат

Сообщение об ошибке: «unable to get local issuer certificate» (curl, Python, PHP), «unable to verify the first certificate» (Node.js) или «incomplete certificate chain»

Причина: сервер отправляет только leaf-сертификат. Chrome часто исправляет это, скачивая промежуточный сертификат сам (как и средство проверки Apple), поэтому в браузере сайт может выглядеть нормально, а curl в Linux, Python, Java, платёжные обратные вызовы и многие приложения падают.

Решение: отправляйте промежуточные сертификаты вместе с leaf. С Let's Encrypt укажите серверу fullchain.pem, а не cert.pem; с другим CA скачайте его промежуточный сертификат и поместите после своего в один файл:

cat your-domain.crt intermediate.crt > fullchain.crt

Самоподписанный сертификат в цепочке

Сообщение об ошибке: «self-signed certificate in certificate chain» (ошибка OpenSSL 19)

Причина: цепочка заканчивается корневым сертификатом, которому клиент не доверяет: частным или корпоративным CA либо прокси или антивирусом, который переподписывает трафик собственным корневым сертификатом. Отправка корневого сертификата, которому клиент доверяет, безвредна, просто не нужна.

Решение: для публичных сайтов используйте сертификат публичного CA или установите частный корневой сертификат на клиентах, которым он нужен. Если убрать корневой сертификат из цепочки сервера, станет аккуратнее, но эту ошибку не исправит.

Неправильный порядок сертификатов

Сообщение об ошибке: проверка цепочки не проходит у некоторых клиентов, или они сообщают, что сертификату нет доверия.

Причина: сертификаты в файле цепочки идут в неправильном порядке. TLS 1.3 требует, чтобы собственный сертификат сервера шёл первым, а остальные следовали по порядку, но предписывает клиентам справляться и с другим порядком (RFC 8446 §4.4.2); старые или более строгие клиенты могут не справиться.

Решение: поставьте leaf-сертификат первым, затем каждый промежуточный, начиная с того, который подписал ваш leaf.

Просроченный сертификат в цепочке

Сообщение об ошибке: «certificate has expired», хотя дата окончания вашего leaf-сертификата в порядке.

Причина: истёк срок сертификата выше по цепочке. Самый известный случай: DST Root CA X3 компании IdenTrust, который перекрёстно подписывал корневой сертификат Let's Encrypt, истёк 30 сентября 2021 года, и устройства, не доверявшие ISRG Root X1 (а также клиенты на OpenSSL 1.0.x), перестали открывать сайты на Let's Encrypt.

Решение: скачайте актуальный промежуточный сертификат у вашего CA и замените старый. Затем проверьте обновлённую цепочку в нашей SSL-проверке.

Лучшие практики цепочки сертификатов

• Всегда отправляйте промежуточные сертификаты — не рассчитывайте, что браузеры починят цепочку; приложения и API-клиенты этого не сделают.
• Корневой сертификат необязателен — клиенты используют собственную копию, поэтому отправка доверенного им корневого лишь добавляет байты; перекрёстно подписанный корневой сертификат для старых устройств — осознанное исключение.
• Соблюдайте порядок — сначала leaf, затем промежуточные, начиная с подписавшего ваш leaf и выше.
• Автоматизируйте продление — сертификаты, выданные с марта 2026, действуют не более 200 дней, а в марте 2027 срок сократится до 100, и Let's Encrypt переходит на 64-дневные сертификаты в феврале 2027.
• Проверяйте после каждого продления или переезда — CA может сменить промежуточные сертификаты между продлениями. После этого прогоните сайт через SSL-проверку.
• Следите за каждым именем — www, голый домен и каждый поддомен могут обслуживаться разными сертификатами и цепочками. Поиск поддоменов показывает имена, которые покрывали ваши сертификаты, по публичным журналам сертификатов.