SSL certificate chain или цепочка доверия — последовательность сертификатов, которая связывает сертификат сайта с корневым центром сертификации (Root CA), которому браузер уже доверяет. В большинстве ситуаций цепочка выглядит так: сертификат сайта (leaf) — промежуточный сертификат (Intermediate CA) — корневой сертификат (Root CA). Благодаря этой связи браузер может проверить, что сертификат действительно выдан доверенным центром сертификации, а не создан неизвестным источником.

Важность сохранения последовательности в цепочке доверия, она нужна не только для самого сертификата, но и для корректной работы веб-сайта в различных браузерах, совместимости с операционными системами и клиентскими устройствами. Даже при наличии действительного сертификата соединение завершится ошибкой, если сервером передается некорректная цепочка доверия. Для новичков будет полезен другой материал из нашей базы знаний – что такое SSL-сертификат. Ознакомьтесь с этой статьей, чтобы иметь базовые представления о SSL/TLS-сертификате.

Из чего состоит цепочка доверия

Чтобы лучше понимать принцип SSL certificate chain, просто запомните вид цепочки, приведенной ниже:

Root CA — Intermediate CA — Leaf certificate

Давайте рассмотрим каждую составляющую вышеприведенной цепочки доверия.

Root CA

Root CA – корневой центр сертификации с изначально выстроенным доверием со стороны браузера или операционной системы. Это верхнее звено цепочки доверия. Находится в trust store - так называется специальное хранилище для доверенных сертификатов.

Trust store является одним из атрибутов ОС и веб-браузеров, веб-серверу не нужно отправлять root-сертификат клиенту – благодаря trust store и наличию доверенного сертификата он заранее определяется как доверенный корень. Так как Root CA является сертификатом верхнего уровня, у него есть собственная цифровая подпись.

Но тут важно учитывать, что root CA и self-signed certificate — не одно и то же в практическом смысле. Корневой сертификат действительно является самоподписанным, но его отличие заключается в том, что он установлен как доверенный якорь в trust store. Обычный self-signed сертификат сайта такого доверия автоматически не получает.

Intermediate CA

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

В цепочке доверия может быть несколько промежуточных сертификатов. В таком случае они будут именоваться как Intermediate CA 1, Intermediate CA 2 и так далее. Это необходимо для обеспечения более высокой защищенности центра сертификации. Всё дело в том, что использование Root CA для прямой выдачи сертификатов сайтам сильно бы пошатнуло вопрос безопасности. Использование промежуточного звена решает эту задачу.

Даже если случится так, что один из один из Intermediate CA будет скомпрометирован, последствия можно ограничить, не подвергая непосредственному риску корневой ключ.

Leaf certificate

Leaf certificate или end-entity certificate — непосредственно сертификат конкретного сайта. Так как его подписывается промежуточный Intermediate CA, браузеру важно убедиться в том, что он не был скомпрометирован и что он связан с доверенным Root CA.

Полноценная криптографическая цепочка выглядит следующим образом:

сертификат сайта — подписан Intermediate CA — подписан Root CA

В этой цепочке сервер передаёт leaf и необходимые intermediate-сертификаты. Корневой сертификат в нормальной конфигурации передавать не требуется, поскольку он должен находиться в trust store клиента.

Как браузер проверяет цепочку

После открытия пользователем HTTPS-сайта, сервер направляет в браузер определенные сертификаты, упрощенно процесс можно представить так:

  1. Сервер отправляет leaf-сертификат и intermediate-сертификаты. В этом время клиент получает сертификат сайта и необходимые промежуточные звенья цепочки.

  2. Браузер определяет, кому выдан сертификат сайта. Проверяются доменное имя, срок действия и другие параметры сертификата.

  3. Проверяется криптографическая подпись.Браузер проверяет, действительно ли leaf подписан соответствующим промежуточным центром сертификации.

  4. Проверяется intermediate-сертификат. Его подпись должна соответствовать следующему звену цепочки — другому Intermediate CA или Root CA.

  5. Цепочка должна привести к доверенному корню. Браузер или операционная система ищет соответствующий Root CA в своём trust store.

  6. Дополнительно проверяются другие условия доверия. В зависимости от клиента учитывается назначение сертификата, алгоритмы, ограничения CA, отзыв сертификата и другие параметры.

Если все необходимые условия выполнены, браузер может считать сертификат доверенным.root-сертификат не является частью обычной передачи сертификатов от веб-сервера. Сервер не должен отправлять его вместе с leaf и intermediate.Доверенный root обычно не передаётся сервером, а уже находится у клиента в trust store. Сам файл root-сертификата теоретически может находиться на сервере как часть локальной конфигурации или набора CA, но отправлять его браузеру для обычного HTTPS-соединения не нужно.

Почему сервер должен отдавать полную цепочку

Зачастую проблема с HTTPS возникает, когда сервер настроен только на передачу leaf-сертификата.

Представим ситуацию:

Сервер — Leaf certificate

Но клиенту необходимо проверить:

Leaf — Intermediate — Root

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

Особенно заметно это на разных устройствах и программных платформах. Один клиент может уже иметь нужный intermediate в своём локальном хранилище или уметь получить его другим способом, а другой — нет. Сайт, который открывается на одном устройстве, при неправильно настроенной цепочке может выдавать ошибку на другом.

Практический симптом — сообщения вроде:

  • incomplete certificate chain;

  • unable to get local issuer certificate;

  • certificate verify failed.

Точная формулировка зависит от браузера, операционной системы и используемого программного обеспечения.

Важно понимать: проблема с цепочкой не обязательно означает, что сам SSL-сертификат просрочен или недействителен. Leaf может быть совершенно корректным, но сервер может неправильно передавать связанные с ним промежуточные сертификаты.

Для владельца сайта на VPS это одна из причин, почему автоматическая настройка SSL удобнее ручной конфигурации. Если используемая панель управления поддерживает автоматическую установку сертификата и цепочки, она может сама добавить необходимые intermediate-сертификаты в конфигурацию веб-сервера.

При использовании VPS от Leneex конкретное поведение нужно проверять для выбранной панели управления: возможности cPanel, Plesk, DirectAdmin, FASTPANEL и HestiaCP могут отличаться.

Как проверить цепочку сертификатов самостоятельно

Проверить HTTPS-цепочку можно двумя удобными способами: через онлайн-сервис или из командной строки.

Вариант 1. SSL Labs

Для быстрой проверки сайта рекомендуем пользоваться SSL Server Test от Qualys SSL Labs. Сервис анализирует конфигурацию публичного SSL/TLS-сервера и показывает информацию о сертификатах, цепочке доверия и других параметрах HTTPS.

SSL Server Test — Qualys SSL Labs" (https://www.ssllabs.com/ssltest)

Просто укажите доменное имя и запустите проверку. Если цепочка настроена неправильно, отчёт поможет определить, какое звено отсутствует или вызывает проблему.

Вариант 2. OpenSSL

Для технической проверки можно использовать OpenSSL. Актуальная документация OpenSSL 3.6 подтверждает наличие команды s_client и параметров -connect, -servername, -showcerts и -verify_return_error.

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


Например, для просмотра сертификатов, которые сервер отправляет при подключении к HTTPS:

openssl s_client -connect ВАШ_САЙТ.com:443 -servername ВАШ_САЙТ.com -showcerts

Здесь ВАШ_САЙТ.com нужно заменить на домен проверяемого сайта.

Параметр -servername важен для серверов, на которых используется SNI и размещено несколько HTTPS-сайтов на одном IP-адресе. OpenSSL отдельно отмечает, что -showcerts отображает сертификаты, отправленные сервером, и сам по себе не означает, что цепочка успешно проверена.

Для диагностики ошибок проверки можно использовать режимы верификации OpenSSL, но конкретную команду следует подбирать с учётом версии OpenSSL, доверенного хранилища и задачи проверки. s_client является диагностическим инструментом и по умолчанию способен продолжать работу даже при некоторых ошибках проверки; -verify_return_error изменяет такое поведение.

Заключение

Цепочка доверия — механизм, который связывает сертификат конкретного сайта с корневым центром сертификации, которому браузер уже доверяет. В типичной конфигурации она состоит из leaf-сертификата сайта, одного или нескольких intermediate-сертификатов и доверенного Root CA.

Главная практическая задача владельца сайта — правильно настроить сервер так, чтобы он передавал leaf и необходимые intermediate-сертификаты. Root-сертификат при этом обычно не отправляется: он уже находится в доверенном хранилище операционной системы или браузера.

В случае использования виртуального сервера от Leneex настройка цепочки зависит от выбранной панели управления и её возможностей автоматической установки SSL. Вам не нужно вручную собирать chain-файл: необходимые промежуточные сертификаты устанавливаются в рамках процедуры настройки SSL.

Подробнее о SSL-сертификатах Leneex — на странице услуги: здесь можно выбрать подходящий вариант и проверить, как автоматическая установка сертификата работает в используемой панели управления.