Как проверить корневой центр сертификации цифровой подписи

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

Что такое корневой центр сертификации и зачем его проверять

В инфраструктуре открытых ключей (PKI) каждый сертификат подписан более высоким уровнем. Цепочка выглядит так: конечный сертификат → промежуточный(е) сертификат(ы) → корневой сертификат. Корневой ЦС является самоподписанным и выступает опорой доверия. Операционные системы и браузеры хранят список доверенных корневых сертификатов; если нужный корневой сертификат отсутствует или помечен как недоверенный, цепочка разрывается.

Проверка корневого ЦС позволяет:

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

  Основные способы проверки

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

  Сравнение методов по платформам

  Платформа	Инструмент	Как получить цепочку	Где смотреть корневой ЦС
  Windows	certutil, snap-in «Сертификаты», PowerShell	Импортировать подписанный файл или указать сертификат в свойствах подписи	Вкладка «Путь сертификации» → последний элемент цепочки
  macOS	Keychain Access, security, openssl	Открыть подписанный файл или использовать security verify-signature	В окне сертификата → «Цепочка доверия» → самый верхний сертификат
  Linux	openssl, certutil (из пакета libnss3-tools)	Выполнить openssl pkcs7 -in file.p7b -print_certs -text или аналогично для других форматов	Последний выданный сертификат в выводе – корневой

  Проверка в Windows

  Windows предоставляет несколько удобных способов посмотреть цепочку сертификатов и статус корневого ЦС.

  Через свойства файла
• Щёлкните правой кнопкой мыши по подписанному файлу (например, .exe, .dll, .pdf) и выберите «Свойства».
• Перейдите на вкладку «Цифровые подписи».
• Выберите нужную подпись и нажмите «Сведения».
• В окне сведений нажмите «Просмотреть сертификат».
• Откройте вкладку «Путь сертификации». Последний элемент в списке – корневой сертификат.
• Если рядом с корневым сертификатом изображён жёлтый восклицательный знак или надпись «Не доверен», значит система не считает его доверенным.

С помощью certutil

Командная строка позволяет быстро вывести цепочку и проверить статус trust.

certutil -verify -urlfetch <путь_к_файлу>

В выводе ищите строки вида «Сертификат № X: → ». Последний Issuer, совпадающий с Subject, – корневой ЦС. Если в конце вывода присутствует «CertUtil: -verify command FAILED: 0x800b0109 (A certificate chain processed, but terminated in a root certificate which is not trusted by the provider.)», это указывает на отсутствие доверия к корневому сертификату.

Через PowerShell

Получить объект сертификата и вывести цепочку:

$cert = Get-PfxCertificate -FilePath <путь_к_файлу>
$chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
$chain.ChainPolicy.RevocationMode = [System.Security.Cryptography.X509Certificates.X509RevocationMode]::Online
$chain.Build($cert) | Out-Null
$chain.ChainElements | ForEach-Object { $_.Certificate.Subject }

Последний выданный субъект – корневой ЦС. Свойство $chain.ChainStatus покажет, есть ли ошибки доверия.

Проверка в macOS

В macOS цепочку сертификатов можно inspect через приложение «Связка ключей» или утилиту security.

Через Связку ключей

1. Дважды щёлкните по подписанному файлу (обычно .pkg, .dmg или .app). Система предложит проверить подпись.
2. В появившемся окне нажмите «Показать сертификат».
3. Перейдите на вкладку «Доверие». Вверху будет указано корневое имя.
4. Если рядом с корневым сертификатом стоит значок предупреждения, значит он не отмечен как доверенный.

С помощью security

Для проверки подписи пакета:

security verify-signature -R <путь_к_пакету>

Вывод содержит строки «Signed by» и «Chain». Последний элемент в цепочке – корневой сертификат. Если после проверки появляется сообщение «Failed to verify signature», а в деталях указано «Untrusted root», значит корневой ЦС не доверен.

Через openssl (универсально)

Если файл представлен в формате CMS/PKCS#7 (.p7b, .p7s) или как отдельный сертификат:

openssl pkcs7 -in файл.p7b -print_certs -text -noout

В блоке «Certificate chain» каждый сертификат помечен номерами 0, 1, 2… Последний (с наибольшим номером) – корневой. Его параметры Subject и Issuer совпадают.

Проверка в Linux

На большинстве дистрибутивов достаточно установить пакет openssl (обычно уже присутствует) и использовать его для анализа цепочки.

Через openssl для различных форматов

• PKCS#7 / P7B:openssl pkcs7 -in файл.p7b -print_certs -text -noout
• PEM‑сертификат (например, вытянутый из файла):openssl x509 -in cert.pem -text -noout
• Отдельная подпись (PGP, signtool) – сначала извлеките сертификат:gpg —list-packets файл.sig (далее найдите блок с сертификатом и скопируйте его в PEM‑файл).

После получения вывода ищите последний блок «Certificate». Поле Issuer будет указывать на себя же (Subject == Issuer) – это корневой ЦС.

Проверка доверия в хранилище системы

В Linux доверенные корневые сертификаты обычно хранятся в каталоге /etc/ssl/certs (или в зависимости от дистрибутива – /usr/local/share/ca-certificates). Чтобы убедиться, что корневой сертификат присутствует:

openssl x509 -in /etc/ssl/certs/ca-certificates.crt -noout -subject -issuer | grep «корневое_имя»

Если строка не найдена, сертификат не доверен системой.

Что делать, если корневой ЦС не доверен

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

• Корневой ЦС действительно не входит в базу доверенных (например, корпоративный внутренний ЦС).
• Корневой сертификат устарел и был заменён новым.
• Система не обновляла список доверенных корней длительное время.
• Файл подписи повреждён или подменён.

Практический порядок действий:

1. Определите источник корневого сертификата. Если это внутренний ЦС вашей организации, запросите у ИТ‑отдела актуальный корневой файл и добавьте его в доверенное хранилище (в Windows – через «Сертификаты» → «Доверенные корневые центры сертификации», в macOS – через «Связку ключей», в Linux – скопировать в /usr/local/share/ca-certificates и выполнить update-ca-certificates).
2. Если корневой ЦС публичный (например, DigiCert, Sectigo, GlobalSign), проверьте дату его выпуска. Старые корни могут быть удалены из доверия из‑за уязвимостей (например, переход от SHA‑1 к SHA‑256). В таком случае установите обновлённый пакет корневых сертификатов от производителя ОС.
3. После добавления корневого сертификата повторно выполните проверку цепочки. Если теперь путь показывает «Trusted» и нет ошибок отзыва, подпись считается валидной.
4. Если даже после добавления корневого ЦС проверка всё равно падает, проверьте статус отзыва (CRL/OCSP) для промежуточных и конечного сертификата – возможно, они сами отозваны.
5. В случае сомнений в подлинности файла (например, получен из ненадёжного источника) воздержитесь от использования и выполните дополнительный антивирусный скан.

Типичные ошибки и как их избежать

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

Ошибка 1: Считать, что наличие подписи гарантирует доверие

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

Ошибка 2: Не обновлять хранилище корневых сертификатов

Операционные системы периодически исключают устаревшие корни (например, те, которые используют слабые хеш‑функции). Если вы не применяете обновления ОС, ваше хранилище может содержать недоверенные корни, что приводит к ложному ощущению безопасности.

Как избежать: включайте автоматическое обновление системы или регулярно запускайте соответствующие утилиты (wuauclt /detectnow в Windows, softwareupdate в macOS, apt update && apt upgrade в Debian‑based Linux).

Ошибка 3: Проверять только конечный сертификат

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

Как избежать: при использовании openssl или certutil требуйте вывод полной цепочки (-showcerts, -verbose) и проверяйте каждый элемент.

Ошибка 4: Игнорировать статус отзыва

Даже если корневой ЦС доверен, промежуточный или конечный сертификат может находиться в списке отзыва (CRL) или отвечать отрицательно на запрос OCSP.

Как избежать: многие утилиты имеют флаги проверки отзыва (certutil -verify -urlfetch делает это автоматически; в openssl нужно добавить -crl_download и использовать -ocsp_uri). Если ваш инструмент не поддерживает проверку отзыва встроено, воспользуйтесь онлайн‑сервисами OCSP (только для информационных целей, не передавайте закрытые ключи).

Практический итог

Главный принцип проверки цифровой подписи – убедиться, что вся цепочка доверия от конечного сертификата до корневого ЦС является валидной, доверенной и не отозванной. Для этого:

1. Получите полную цепочку сертификатов (инструменты: свойства файла, certutil, security, openssl).
2. Определите корневой сертификат – последний элемент, где Subject == Issuer.
3. Проверьте, отмечен ли этот корневой сертификат как доверенный в хранилище ОС.
4. Убедитесь, что ни один элемент цепочки не находится в списке отзыва (CRL/OCSP).
5. Если корневой ЦС не доверен, добавьте его из надёжного источника или обновите пакет корневых сертификатов системы.

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