Промежуточный сертификат: зачем он нужен при проверке файла и как избежать ошибки «цепочка не доверенная»

Промежуточный сертификат — это связующее звено между сертификатом вашего сервера или подписанного файла и корневым сертификатом, которому операционная система доверяет изначально. Если это звено отсутствует, проверка заканчивается ошибкой «цепочка не может быть построена» или «сертификат не доверенный», даже если сам сертификат полностью действителен. Именно промежуточные сертификаты чаще всего становятся причиной проблем с HTTPS-соединениями, электронной подписью документов и подключением программ к защищённым сервисам.

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

Как устроена цепочка доверия

Система сертификатов построена по иерархическому принципу. В её основе лежат корневые сертификаты — они встроены в операционные системы и браузеры заранее. Корневые центры сертификации хранят свои ключи в изолированной среде и почти никогда не выпускают сертификаты напрямую для сайтов и организаций. Вместо этого они делегируют эту работу подчинённым центрам через промежуточные сертификаты.

Типичная цепочка выглядит так:

• Корневой сертификат — находится в доверенном хранилище вашей системы, его подлинность подтверждена производителем ОС или браузера.
• Промежуточный сертификат — выдан корневым центром и подтверждает право промежуточного центра выпускать конечные сертификаты. Таких звеньев может быть одно или несколько.
• Конечный (листовой) сертификат — то, что вы получаете для своего домена, сервера или файла с электронной подписью.

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

Почему без промежуточного сертификата проверка не проходит

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

Частичное исключение — механизм AIA (Authority Information Access). Многие современные сертификаты содержат адрес, по которому можно автоматически загрузить недостающий промежуточный сертификат. Браузеры часто этим пользуются, поэтому сайт может открываться без ошибок в браузере, но падать в других программах: библиотеках, мобильных приложениях, почтовых клиентах, утилитах командной строки. Это одна из самых коварных ситуаций — ошибка проявляется не везде, а только у части пользователей или сервисов.

Типичные сценарии, где проблема всплывает

• Веб-сервер. Сайт работает в Chrome, но curl, старый браузер или приложение-клиент сообщают об ошибке проверки сертификата.
• Электронная подпись файлов. Документ подписан, но при проверке другая сторона получает сообщение о том, что сертификат подписанта не может быть проверен.
• API и интеграции. Сервис принимает соединения от одних систем и отвергает от других, хотя настройки идентичны.
• Мобильные приложения. На части устройств соединение не устанавливается из-за отсутствующего звена в цепочке.

Как проверить, полная ли цепочка в вашем файле

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

Проверка PEM-файла (текстовый формат с блоками BEGIN/END)

1. Откройте файл текстовым редактором и посчитайте количество блоков BEGIN CERTIFICATE. Один блок — почти наверняка неполная цепочка: обычно требуется минимум два блока (конечный плюс промежуточный).
2. Для каждого блока выполните просмотр сведений о сертификате стандартной утилитой OpenSSL: команда вида openssl x509 -in файл.pem -noout -subject -issuer покажет, кому выдан сертификат и кто его выдал.
3. Сравните поле issuer одного сертификата с полем subject следующего: они должны совпадать. Разрыв между этими полями означает отсутствие звена.
4. Убедитесь, что последнее звено в цепочке соответствует корню, который есть в доверенном хранилище вашей системы.

Проверка установленного сертификата на сервере

Если речь о веб-сервере, удобнее проверить цепочку так, как её увидит внешний клиент: запросить соединение с указанием порта и посмотреть, какие сертификаты сервер отдаёт. Утилита OpenSSL позволяет вывести всю предъявленную цепочку целиком. Признак проблемы — в выводе присутствует только конечный сертификат, а строка о глубине цепочки показывает единственный элемент.

Проверка подписанного документа

При работе с электронно-подписанными файлами используйте штатные средства проверки: встроенные просмотрщики PDF, криптопровайдеры или утилиты операционной системы. Они показывают статус цепочки явно. Если статус — «не удалось построить цепочку» или «издатель не найден», первым делом проверяйте, установлены ли промежуточные сертификаты вашего удостоверяющего центра в хранилище системы.

Где взять недостающие промежуточные сертификаты

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

• Центр сертификации или его партнёр. При выпуске сертификата вместе с ним обычно выдаётся архив с «цепочкой» или «bundle» — файлом, содержащим промежуточные звенья. Ищите файлы с названиями вроде chain, ca-bundle, intermediate.
• Страница загрузки центра сертификации. У каждого публичного УЦ есть раздел с сертификатами для скачивания; выбирайте именно тот промежуточный сертификат, который соответствует вашему продукту и году выпуска.
• Поле AIA в самом сертификате. Как упоминалось выше, там часто указан прямой адрес загрузки недостающего звена.

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

Как правильно собрать полный файл цепочки

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

1. Подготовьте конечный сертификат и скачанные промежуточные сертификаты в формате PEM.
2. Определите порядок: у конечного сертификата issuer должен совпадать с subject первого промежуточного, у первого промежуточного — со вторым, и так далее.
3. Склейте файлы в правильном порядке в один текстовый файл (при ручной склейке следите, чтобы каждый блок BEGIN/END CERTIFICATE начинался с новой строки).
4. Укажите собранный файл в настройках сервера или приложения вместо одиночного сертификата.
5. Перезапустите сервис и повторно проверьте цепочку внешним инструментом, а не только локально.

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

Сравнение типичных ситуаций и решений

Ситуация	Вероятная причина	Что делать
Ошибка появляется только в некоторых программах	Сервер отдаёт неполную цепочку; часть клиентов достраивает её через AIA, часть — нет	Добавить промежуточные сертификаты в конфигурацию сервера
Цепочка не строится после продления сертификата	Новый сертификат выпущен от другой промежуточной цепочки	Скачать актуальную цепочку у издателя и заменить старую
Подписанный документ не проверяется у получателя	На стороне получателя не установлены сертификаты удостоверяющего центра	Передать получателю цепочку или ссылку на неё, установить сертификаты в хранилище
Issuer и subject соседних звеньев не совпадают	В цепочку попал чужой или устаревший промежуточный сертификат	Пересобрать цепочку заново из сертификатов конкретного издателя
Ошибка «истёк срок действия» у промежуточного звена	Используется снятая с использования цепочка	Запросить у издателя действующую цепочку и обновить её

Распространённые ошибки

• Ориентация только на браузер. То, что сайт открывается в основном браузере, не доказывает корректность конфигурации: браузеры агрессивнее достраивают цепочку автоматически.
• Смешивание форматов. Промежуточный сертификат в формате DER нельзя просто вставить в PEM-файл; сначала его нужно преобразовать в текстовый формат.
• Неправильный порядок звеньев. Некоторые серверы строго ожидают цепочку от конечного сертификата к корню; перепутанный порядок приводит к ошибкам даже при полном наборе файлов.
• Игнорирование даты. Промежуточные сертификаты тоже имеют срок действия. Цепочка, работавшая годами, может сломаться в момент истечения срока промежуточного звена.
• Копирование цепочки от другого владельца сертификатов. Даже у одного центра сертификации разные продукты используют разные промежуточные звенья.

Ограничения и нюансы, о которых стоит помнить

Даже полная цепочка не гарантирует успешной проверки. Программа дополнительно проверяет срок действия каждого звена, назначение сертификата (например, разрешено ли ему подписывать другие сертификаты), состояние отзыва и требования политик. Поэтому при диагностике важно читать точный текст ошибки: «unable to build chain», «certificate expired», «revoked» и «untrusted root» означают совершенно разные проблемы и разные решения.

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

Наконец, детали реализации различаются между платформами: Windows, Linux, macOS и мобильные системы по-разному относятся к автоматической загрузке недостающих звеньев, кэшированию и обработке перекрёстных подписей. Практическое правило — считать обязательным полное предъявление цепочки сервером или отправителем, не полагаясь на способность клиента достроить её самостоятельно.

Что делать дальше

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

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