Цепочка сертификатов: как проверить доверие

Один сотрудник открывает внутренний сайт в браузере, а у другого приложение сообщает: «Сертификат не принят». Чтобы разобраться, нужно понять, кто подтвердил сертификат сайта и кому доверяет каждый клиент — браузер или приложение.

Цепочка сертификатов связывает сертификат сервера с заранее принятой клиентом опорой доверия. В простом примере есть три объекта: сертификат сайта, промежуточный сертификат его издателя и корневой сертификат, которому клиент уже доверяет. Клиент проверяет связи между ними.

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

Названия root, intermediate и leaf описывают роли. Issuing описывает, кто выдал конкретный сертификат: это не обязательная дополнительная ступень. Между корнем и конечным сертификатом может быть несколько промежуточных центров или ни одного.

Сервис portal.example.org предъявляет свой сертификат. Его подписал условный центр выдачи сертификатов Example Issuing CA. CA — сокращение от Certificate Authority, то есть удостоверяющий центр. Сертификат этого центра подписан корневым центром, которому доверяет проверяющий клиент. Это учебная модель, а не описание внедрения конкретного заказчика.

Что такое самоподписанный сертификат

Самоподписанный сертификат (self-signed) подписан приватным ключом, соответствующим открытому ключу в этом же сертификате. Для проверки его подписи не нужен сертификат другого издателя. Но это ещё не основание доверять владельцу: любой может создать такую пару ключей и сертификат.

Здесь два отдельных вопроса: «Соответствует ли подпись указанному ключу?» и «Почему мы принимаем этот ключ как доверенный?» Первый решает криптографическая проверка. Второй — заранее заданные правила клиента.

Корневой сертификат и сертификат сервера — разные роли

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

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

Почему корню доверяют

Корневой сертификат обычно самоподписанный. Основание доверять ему задаётся отдельно — поставщиком доверенного хранилища или администратором по согласованной политике. Получить файл корня от сервера и принять его как доверенный — разные действия.

Опора доверия — более широкое понятие, чем файл самоподписанного сертификата: это принятые проверяющей стороной сведения о доверенном ключе и связанных условиях. В нашем примере она представлена корневым сертификатом. Модель проверки пути описана в RFC 5280 ↗.

Сервер предъявляет, клиент проверяет

Сертификат сервера отвечает на вопрос «Кто перед нами?». Промежуточный сертификат помогает проверить, кто подтвердил сведения о сервере. Корневой сертификат в настройках клиента задаёт, от какого ключа клиент готов начинать проверку.

При подключении с проверкой сертификата сервер предъявляет сертификат сервиса и обычно необходимые промежуточные сертификаты. Корневой сертификат обычно не отправляют: клиент должен уже иметь подходящую опору доверия. Добавление корня в ответ сервера не заставит клиента принять его.

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

Правила передачи сертификатов задаёт TLS 1.3 — RFC 9846 ↗. Реальные варианты путей и перекрёстное подписание показаны у Let’s Encrypt ↗. Поэтому для разных клиентов иногда подходят разные пути к доверенной опоре.

Что ещё учитывает программа

В сертификате есть поле Subject — кого он обозначает, и Issuer — кто его выпустил. Совпадение Subject предполагаемого издателя с Issuer проверяемого сертификата помогает найти сертификат-кандидат, но не доказывает правильность связи. Проверяющая сторона должна проверить подпись и допустимость использования ключа издателя. Дополнительно учитываются ограничения центров, сроки, разрешённые назначения и другие требования политики.

Для HTTPS отдельно проверяется соответствие имени сервиса сертификату; современная модель проверки имён опирается на расширение Subject Alternative Name (SAN), в котором перечислены имена сервиса. Проверка отзыва тоже зависит от клиента и его политики: успешное построение пути само по себе не доказывает, что статус отзыва проверен. Подробнее об имени — в RFC 9525 ↗.

Сертификат клиента и доказательство владения его ключом — другая задача. Установка доверенного корня помогает проверять чужие сертификаты, но не выдаёт устройству собственное удостоверение и приватный ключ.

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

Для проверки цепочки приватные ключи не нужны. Сведения о сертификатах и адресах могут раскрывать внутренние имена, поэтому диагностические материалы требуют подходящего канала передачи.

Фактическое соединение

Адрес, порт и точка завершения TLS определяют, кто предъявляет сертификат. Это может быть сам сервис, прокси или балансировщик. Имя, которое проверяет клиент, не всегда совпадает с названием записи в каталоге. Точное сообщение и время ошибки связывают наблюдение с конкретным подключением.

Набор переданных сертификатов

Сервер предъявляет собственный сертификат и необходимые промежуточные сертификаты. Если промежуточного сертификата не хватает, результат зависит от того, располагает ли клиент его копией или поддерживает получение недостающих данных.

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

Например, сервер передаёт только свой сертификат. Браузер находит сохранённый промежуточный сертификат и строит путь до принятого корня. Приложению промежуточного сертификата не хватает, поэтому оно отклоняет подключение. Передача сервером необходимого промежуточного сертификата устраняет эту причину без добавления нового доверенного корня.

Настройки конкретного клиента

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

Другие условия проверки

Построенный путь ещё должен соответствовать применимым ограничениям: срокам, назначению, полномочиям центров и политике клиента. Для HTTPS отдельно важно имя сервиса; на результат влияет и время системы. Проверка отзыва зависит от настроек и доступности источников статуса. Поэтому путь до принятого корня сам по себе не подтверждает выполнение всех условий.

Типовые причины отказа

Одна внешне похожая ошибка может иметь разные причины. В таблице указано, с какой частью системы связана каждая из них.

Три действия, которые не устраняют причину

• Отключить проверку TLS — значит убрать защитную проверку вместо исправления.
• Прислать корневой сертификат с сервера — значит передать файл, а не согласовать доверие.
• Признать настройку исправной по одному браузеру — значит не проверить проблемный клиент.

Результат проверки понятен в контексте соединения, предъявленного набора сертификатов и правил клиента:

• Соединение: адрес, порт, точка завершения TLS, клиент и его версия.
• Наблюдение: точная ошибка, время и фактически предъявленный набор сертификатов.
• Условия проверки: имя, хранилище доверия и применимая политика.
• Причина: подтверждённое условие отказа либо гипотеза, для которой ещё не хватает данных.
• Результат: что изменено и как повтор исходного подключения подтвердил исправление.

Повтор подключения исходным приложением после передачи недостающего промежуточного сертификата подтверждает устранение именно этой причины. Успех в другом браузере не даёт такого подтверждения.

Частые вопросы о цепочке доверия

1. Сервер отправил корень. Обязан ли клиент ему доверять? Нет: доверие задаётся проверяющей стороной отдельно.
2. У издателя одинаковое имя в двух сертификатах. Достаточно ли этого? Нет: нужно проверить подпись, ключ и ограничения.
3. В браузере работает, в приложении — нет. Сервер точно исправен? Нет: кэш, хранилища и правила проверки могут различаться.
4. На телефон установили доверенный корень. Получил ли он собственное удостоверение? Нет: это настройка проверки чужих сертификатов; собственный сертификат и ключ — другие объекты.
5. OpenSSL сообщил OK. Значит, приложение подключится? Не обязательно: офлайн-проверка файлов не заменяет подключение исходным приложением с его настройками.
6. Подпись самоподписанного сертификата проверяется. Значит, серверу можно доверять? Это подтверждает связь подписи с ключом в сертификате. Основание принять владельца или ключ как доверенный нужно установить отдельно.

В интерфейсе рядом встречаются три разных признака: роль в цепочке, место хранения и условия доверия. Корневой сертификат описывает роль; «Текущий пользователь» — область Windows; System — связку macOS. Это разные ответы на разные вопросы.

Ниже — распространённые названия. Перевод, набор разделов и внешний вид зависят от версии системы и установленных компонентов; английские имена и короткие коды помогают сопоставить документацию с интерфейсом.

Windows: сначала область, затем хранилище

Например, CurrentUser → Root и LocalMachine → Root — одинаковое назначение хранилища в разных областях. Области не являются ступенями сертификатной цепочки. Пользовательское представление некоторых хранилищ может включать машинные записи; для Personal действуют отдельные правила. Поэтому повтор записи в двух представлениях не обязательно означает две независимые копии.

Области, оснастки и правила просмотра описаны в Microsoft Learn: области хранилищ ↗.

Windows: что означают названия хранилищ

Код CA здесь означает конкретное хранилище промежуточных сертификатов. В общем тексте CA — центр сертификации любого соответствующего уровня. У слов «доверенный издатель» в подписи программы и «издатель сертификата» тоже разный контекст.

Назначения хранилищ приведены в Microsoft Learn: каталог сертификатов ↗; их логическое и физическое устройство — в Microsoft Learn: расположения хранилищ ↗. Подпапки политик и предприятия показывают источник записей и правила управления, а не дополнительных издателей в пути.

macOS: связка, категория и доверие

В System могут лежать промежуточные сертификаты и добавленные корни. В отличие от Windows, здесь нет обязательного соответствия «промежуточный сертификат → отдельная папка CA»: роль определяется самим сертификатом и построенным путём.

У одного объекта отдельно выбираются связка и категория просмотра. Общие принципы описаны в Apple: просмотр связки ключей ↗, различие сертификата и identity — в Apple: сертификат и связанный ключ ↗. Системные корни рассмотрены в Apple Platform Security ↗.

В разделе «Доверие» встречаются «Использовать настройки системы» / Use System Defaults, «Всегда доверять» / Always Trust и «Никогда не доверять» / Never Trust. Первое оставляет решение системной политике; остальные задают явное разрешение или запрет для соответствующего использования. Названия SSL, S/MIME, EAP или подписывания кода обозначают разные назначения проверки, а не уровни цепочки. Поведение политик описано у Apple: политики доверия ↗.

Добавить сертификат в хранилище и принять его как опору доверия — разные действия. Изменение доверия не исправляет подпись, срок или выдачу сертификата. Конкретная программа может применять собственное хранилище и дополнительные правила.

Дополнительно: проверка файлов в OpenSSL

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

Есть три PEM-файла из известного и проверенного источника: server.pem — сертификат сервиса, intermediate.pem — промежуточный, root.pem — согласованная опора доверия. Имена файлов условные. Команда ниже проверена в OpenSSL 3.0.13:

openssl verify \
-no-CApath -no-CAstore \
-CAfile root.pem \
-untrusted intermediate.pem \
-purpose sslserver \
-verify_hostname portal.example.org \
server.pem

В учебном примере результат: server.pem: OK.

• -CAfile задаёт доверенную опору для этой проверки.
• -untrusted передаёт промежуточный сертификат для построения пути; он не объявляется опорой доверия.
• -purpose sslserver проверяет пригодность для сервера TLS, -verify_hostname — имя.
• -no-CApath и -no-CAstore исключают два других стандартных источника доверия. Системное хранилище команда не изменяет.

Как выглядит отказ

Если убрать -untrusted intermediate.pem, когда других источников промежуточного сертификата нет, этот пример завершается сообщением unable to get local issuer certificate на глубине 0. Если вместо root.pem указать другой корень, похожее сообщение возникает на глубине 1. Одинаковая фраза ошибки ещё не доказывает одинаковую причину.

При проверке имени other.example.org вместо portal.example.org пример даёт hostname mismatch. Настройки отзыва в этой команде не заданы: результат OK не является подтверждением проверки отзыва.

Эта команда проверяет файлы, а не работающий сервер. Она не показывает, какой набор сейчас отправляет балансировщик, и не воспроизводит все политики браузера. Семантика параметров и диагностика — в документации openssl verify ↗.

Связь сертификата, открытого ключа и подписи объясняет базовый разбор SSL/TLS-сертификатов.

В разборе mTLS показана проверка клиентского удостоверения и владения ключом. Правила доступа приложения рассматриваются отдельно.