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

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

Что такое отзыв сертификата и как он работает

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

• CRL (Certificate Revocation List) — периодически обновляемый список серийных номеров отозванных сертификатов, подписанный ЦС.
• OCSP (Online Certificate Status Protocol) — протокол запроса‑ответа, позволяющий получить актуальный статус конкретного сертификата в реальном времени.

Оба механизма используют данные, содержащиеся в самом сертификате: точки распространения CRL (CDP) и адрес OCSP‑ответчика (AIA). Для проверки отзыва необходимо извлечь эти точки и выполнить запрос к соответствующему источнику.

Как извлечь информацию из подписи файла

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

Извлечение сертификата из подписи

Большинство форматов подписи (например, CMS/PKCS#7, XML‑DSig, Authenticode) позволяют выделить вложенный сертификат или цепочку сертификатов. Ниже перечислены типичные команды для популярных инструментов:

• certutil (Windows) — certutil -dump подпись.fайл выведет содержимое подписи, включая сертификат(ы).
• OpenSSL — для CMS/PKCS#7: openssl pkcs7 -in подпись.p7b -print_certs -text; для detached подписи Authenticode можно использовать signtool verify /pa /v файл.exe (выведет информацию о сертификате).
• certbot / cfssl — также способны разобрать CMS‑структуры и показать сертификат.

В результате вы получите один или несколько сертификатов в формате PEM или DER. Для дальнейшей проверки нужен именно тот сертификат, которым подпись была создана (обычно первый в цепочке, соответствующий полю signer).

Получение точек распространения CRL и OCSP

В сертификате ищутся расширения:

• CRL Distribution Points (CDP) — один или несколько URL, где можно скачать актуальный CRL.
• Authority Information Access (AIA) — URL OCSP‑ответчика.

Эти значения выводятся теми же утилитами:

• certutil: certutil -dump сертификат.cer — в разделе CRL Distribution Points и Authority Information Access будут указаны адреса.
• OpenSSL: openssl x509 -in сертификат.pem -text -noout — ищем строки X509v3 CRL Distribution Points и X509v3 Authority Information Access.

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

Проверка через CRL

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

Скачивание CRL

Можно использовать любой HTTP‑клиент (браузер, wget, curl) или встроенные возможности утилит:

• certutil: certutil -url CRL fetch http://example.com/crl.crl сохранит CRL во временный файл.
• OpenSSL: openssl crl -download -http http://example.com/crl.crl -out crl.pem (если поддерживается вашей версией).

Проверка наличия серийного номера

Серийный номер сертификата берём из его вывода (обычно hex‑значение). Затем ищем его в CRL:

• certutil: certutil -dump crl.crl — в списке отозванных серийных номеров ищем наш.
• OpenSSL: openssl crl -inform PEM -text -noout -in crl.pem — аналогично ищем серийный номер.

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

Проверка через OCSP

OCSP позволяет получить статус конкретного сертификата без загрузки полного списка. Для этого формируется запрос к OCSP‑ответчику и анализируется ответ.

Формирование и отправка OCSP‑запроса

Наиболее простой способ — использовать OpenSSL:

• openssl ocsp -issuer issuing_ca.pem -cert cert_to_check.pem -url http://ocsp.example.com/ -resp_text
• Где issuing_ca.pem — сертификат ЦС, подписавший проверяемый сертификат (может быть корневым или промежуточным).
• -url — адрес OCSP‑ответчика, взятый из расширения AIA.

Ответ содержит строку cert_to_check.pem: good, revoked или unknown. Если статус revoked — сертификат отозван; good — не отозван на момент запроса; unknown указывает, что ответчик не имеет информации о данном сертификате (возможно, он не поддерживает OCSP для данного ЦС).

Альтернативные инструменты

В Windows можно воспользоваться certutil -verify -urlfetch — утилита сама попытается выполнить проверку через CRL и OCSP, если они доступны, и выведет итоговый результат.

Ограничения и моменты, на которые стоит обратить внимание

Даже при правильном выполнении проверки следует учитывать следующие факторы:

• Актуальность данных. CRL обновляется с определённой периодичностью (например, каждые 24 часа). Если проверка выполняется вскоре после отзыва, но до публикации нового CRL, статус может ошибочно показывать good. OCSP обычно более актуален, но зависит от доступности и своевременности ответчика.
• Доступность точек распространения. Если сервер CRL или OCSP недоступен (сетевые проблемы, блокировка фаерволом), проверка не может быть завершена. В таких случаях некоторые приложения допускают «soft‑fail» (продолжают работу), другие — «hard‑fail» (отклоняют подпись). Необходимо знать политику вашей системы.
• Цепочка доверия. Для корректной проверки OCSP потребуется доверенный сертификат ЦС, подписавший ответ. Если промежуточный ЦС отсутствует в доверенном хранилище, ответ может быть отклонён.
• Отсутствие точек отзыва. Некоторые сертификаты (например, самоподписанные или используемые в закрытых PKI) могут не включать CDP/AIA. В этом случае проверка отзыва возможна только через внутренние механизмы вашей организации.
• Отзыв промежуточного ЦС. Если отозван не конечный сертификат, а один из промежуточных в цепочке, вся цепочка считается недоверенной, даже если конечный сертификат не указан в CRL.

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

Ниже представлен общий алгоритм, который можно адаптировать под доступные инструменты и особенности вашей инфраструктуры.

1. Извлечь сертификат(ы) из подписи файла с помощью certutil, OpenSSL или другого средства.
2. Определить, какой сертификат использовался для подписи (обычно первый в цепочке, соответствующий полю signer).
3. Получить из этого сертификата точки распространения CRL (CDP) и адрес OCSP‑ответчика (AIA).
4. Если доступен CRL:
5. Скачать CRL по одному из указанных URL.
6. Проверить наличие серийного номера сертификата в списке.
7. Если номер найден — сертификат отозван; если нет и CRL свежий — считаем, что не отозван по CRL.

Если CRL недоступен или требуется более актуальная проверка — выполнить OCSP‑запрос:

Сформировать запрос, указав сертификат ЦС (issuer) и URL OCSP‑ответчика.

Проанализировать ответ: good — не отозван, revoked — отозван, unknown — нет данных.

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

Задокументировать результат проверки и принять решение о доверии подписи в соответствии с политикой вашей организации.

Советы по повышению надёжности проверки

• Всегда проверяйте не только конечный сертификат, но и всю цепочку доверия: каждый промежуточный сертификат также должен пройти проверку отзыва.
• При использовании OCSP предпочтительно включать nonce (случайное число) для защиты от повторных атак; многие утилиты делают это автоматически.
• Настройте локальное кэширование CRL и OCSP‑ответов, если ваша система выполняет проверки часто — это уменьшит нагрузку на внешние сервисы и ускорит процесс.
• Регулярно обновляйте список доверенных корневых сертификатов в вашем хранилище, чтобы избежать ситуаций, когда проверка невозможна из‑за отсутствия доверенного issuer.
• В корпоративной среде рассмотрите развертывание собственного OCSP‑ответчика или прокси‑сервера CRL, чтобы гарантировать доступность точек отзыва даже при проблемах с публичными сервисами.

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

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

Для автоматизации этого процесса в скриптах или приложениях рекомендуется использовать библиотеки, поддерживающие проверку отзыва (например, Bouncy Castle, Microsoft Authenticode в .NET, OpenSSL в C/C++), и настраивать политику fail‑closed или fail‑open в зависимости от требуемого уровня безопасности.