Как сравнить цепочки доверия двух цифровых подписей: практический разбор

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

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

Что такое цепочка доверия и почему её нельзя оценивать одной строкой

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

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

Из каких звеньев состоит цепочка

• Конечный сертификат — сертификат подписанта, содержит его имя, открытый ключ, срок действия и ограничения применения.
• Промежуточные сертификаты — связующее звено между конечным сертификатом и корнем; их может не быть вовсе, а может быть несколько уровней.
• Корневой сертификат — точка доверия, самоподписанный сертификат УЦ, находящийся в хранилище доверия проверяющей стороны.
• Дополнительные объекты — списки отзыва (CRL) или протокол OCSP, политики сертификации, метки времени, а также кросс-сертификаты, которыми один корень «перекладывается» на другой.

Пошаговый порядок сравнения двух цепочек

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

1. Определите корневой сертификат каждой цепочки. Зафиксируйте издателя (поле Issuer), отпечаток (thumbprint/fingerprint) и организацию. Отпечатки должны совпадать с теми, что реально присутствуют в вашем хранилище доверия, а не просто выглядеть правдоподобно.
2. Проверьте происхождение корня. Встроен ли он в ОС/браузер по умолчанию, установлен ли групповой политикой организации или добавлен вручную кем-то из сотрудников. Ручная установка — самый частый источник ложного доверия.
3. Сопоставьте длину пути. Посчитайте количество промежуточных звеньев. Разная длина сама по себе не ошибка, но чем длиннее путь, тем больше точек отказа и тем важнее проверить каждое звено.
4. Сверьте сроки действия всех сертификатов. Цепочка действительна только в пересечении сроков всех звеньев. Подпись, сделанная в момент действия сертификата, обычно остаётся проверяемой и после истечения срока — но только если применена метка времени (LTV-архивация); без неё проверка после истечения может сломаться.
5. Проверьте статус отзыва каждого звена. Через CRL или OCSP. Цепочка, в которой отозван даже промежуточный сертификат, недействительна целиком, даже если конечный сертификат формально жив.
6. Сравните назначение ключей. Расширения Key Usage и Extended Key Usage должны допускать именно ту операцию, которую вы проверяете: цифровую подпись документа, неотказуемость (non-repudiation), подписание кода и так далее. Сертификат для шифрования почты не подходит для подписания договоров.
7. Сопоставьте политики сертификации. В расширении Certificate Policies указано, по каким правилам выпущен сертификат. Для квалифицированных электронных подписей это отдельный класс политик; обычные TLS-сертификаты им не эквивалентны.
8. Зафиксируйте результат. Запишите для каждой цепочки: корень, отпечаток, число звеньев, статус отзыва, политику, наличие метки времени. Без такой записи сравнение двух проверок, выполненных в разное время, превращается в догадки.

Ключевые критерии сравнения и что они означают на практике

Критерий	Что проверять	О чём говорит расхождение между цепочками
Корневой УЦ	Издатель, отпечаток, наличие в хранилище доверия	Разные корни означают разный уровень признания: один может быть общепризнанным, другой — локальным
Источник доверия	Встроенный корень, политика организации, ручная установка	Ручной корень работает только там, где его установили; на других машинах подпись окажется недоверенной
Длина пути	Число промежуточных сертификатов	Более длинная цепочка имеет больше зависимостей и требует проверки каждого звена
Статус отзыва	CRL/OCSP для всех звеньев	Отзыв любого звена обнуляет доверие ко всей цепочке независимо от остальных параметров
Политики	Расширение Certificate Policies, класс сертификата	Формально валидная цепочка может не соответствовать требованию к квалифицированной подписи
Метки времени	Наличие timestamp и LTV-данных	Без метки времени долгосрочная проверяемость после истечения сертификатов не гарантируется

Чем отличаются типовые сценарии сравнения

На практике сравнение цепочек возникает в трёх основных ситуациях, и логика действий в них различается.

• Два контрагента присылают подписанные документы. Задача — убедиться, что обе подписи равнозначны для вашего процесса. Здесь главное — политики и корни: если один документ подписан квалифицированной подписью, а второй — корпоративным сертификатом внутри организации отправителя, юридически они не взаимозаменяемы.
• Один и тот же документ подписан дважды разными сертификатами одного человека. Например, старый и новый сертификат. Сравнивайте сроки, статус отзыва старого и то, какая метка времени зафиксирована: подпись, сделанная до отзыва и заверенная меткой времени, обычно остаётся действительной на момент подписания.
• Подпись проверяется на разных системах. Если на одном рабочем месте цепочка строится успешно, а на другом нет, причина почти всегда в различии хранилищ доверия или в отсутствии промежуточных сертификатов, которые не были вложены в файл подписи.

Как выполнить проверку инструментами

Для большинства задач достаточно стандартных средств, без специализированного ПО.

• Windows: двойной щелчок по сертификату открывает вкладку «Путь сертификации», где видна вся цепочка и её статус. Утилита certutil -verify -urlfetch file.cer дополнительно скачивает и проверяет списки отзыва. Для подписанных файлов полезна команда signtool verify /pa /all.
• Linux/macOS: OpenSSL позволяет построить и проверить цепочку командами вида openssl verify -CAfile ca.pem -untrusted intermediate.pem cert.pem, а openssl x509 -text показывает политики, назначения ключей и сроки.
• PDF-документы: просмотрщики вроде Adobe Acrobat показывают дерево подписей, состояние цепочки, метку времени и признак LTV. Проверяйте, что статус именно «подпись действительна», а не «идентичность подписанта подтверждена» — это разные уровни верификации.
• Криптопровайдеры для квалифицированных подписей: в ряде стран используются национальные стандарты и собственные средства проверки (например, КриптоПро CSP и КриптоАРМ в российской практике). Обычные браузерные инструменты такие подписи корректно не оценивают.

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

Типичные ошибки при сравнении цепочек

• Доверие «зелёной галочке» без разбора. Индикатор интерфейса отражает лишь локальную настройку машины. Если корень кто-то установил вручную, галочка будет зелёной и у поддельной цепочки.
• Проверка только конечного сертификата. Отзыв промежуточного УЦ делает недействительными все подписи ниже по цепочке, но поверхностная проверка этого не покажет.
• Игнорирование назначения ключа. Сертификат сервера аутентификации или шифрования не даёт права подписывать документы, хотя цепочка до корня может строиться идеально.
• Смешение технической и юридической валидности. Криптографически корректная подпись может не соответствовать требованиям закона к определённому виду документов. Это два независимых вопроса.
• Проверка без учёта времени подписания. Сравнивая цепочку «сегодня», легко ошибочно забраковать подпись, которая была действительна в момент создания и защищена меткой времени.
• Отсутствие промежуточных сертификатов. Если отправитель не вложил их в файл, часть систем не достроит цепочку, хотя все данные доступны в интернете. Прежде чем считать цепочку неполной, уточните формат подписи.

Если условия такие — действуйте так

• Обе цепочки заканчиваются на одном корне, статусы чистые. Дальнейшее сравнение сводится к политикам и назначению ключей под вашу задачу; при совпадении подписи равноценны.
• Корни разные, оба встроены в ОС. Технически обе подписи проверяемы повсеместно, но для документов с юридическими требованиями сверьте класс политик: общий публичный корень не заменяет квалифицированный сертификат.
• Один корень установлен вручную. Запросите у владельца обоснование установки и проверьте отпечаток по официальному источнику УЦ. Пока происхождение не подтверждено, считайте эту цепочку менее надёжной.
• Одна цепочка длиннее за счёт кросс-сертификата. Кросс-подписание — легальный механизм, которым корень одного УЦ признаётся через корень другого. Проверьте, что кросс-сертификат актуален и не отозван.
• Инструмент сообщает об ошибке отзыва. Не игнорируйте и не отключайте проверку отзыва ради «зелёного результата». Уточните доступность CRL/OCSP и повторите проверку позже; устойчивая недоступность — тоже повод для осторожности.

Частые вопросы

Можно ли считать подпись действительной, если цепочка строится, но корень добавлен вручную?

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

Обязательно ли совпадение корней у двух сравниваемых подписей?

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

Что делать, если промежуточный сертификат не приложен к подписи?

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

Насколько можно доверять проверке, выполненной одним инструментом?

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

С чего начать прямо сейчас

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

Материал носит информационный характер и описывает общую методику проверки. Конкретные требования к электронным подписям, признаваемым корневым центрам и юридической силе документов зависят от страны, отрасли и типа документа; при существенных для вас решениях сверяйтесь с актуальными нормативными требованиями и консультируйтесь со специалистом по электронной подписи.