Как работает проверка цепочки доверия в Windows Authenticode

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

Что такое Authenticode и зачем нужна цепочка доверия

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

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

1. Извлечение подписи из файла
2. Построение цепочки сертификатов от конечного сертификата до доверенного корня
3. Валидация каждого сертификата в цепочке (сроки, отзыв, назначение)
4. Проверка временной метки (если она есть)
5. Принятие окончательного решения о доверии

Детали каждого этапа

Извлечение подписи

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

• зашифрованный хеш файла;
• сертификат издателя (или несколько сертификатов, если используется промежуточный центр);
• опциональная временная метка, подписанная центром timestamping authority (TSA).

Построение цепочки

Из извлечённого сертификата начинается построение цепочки доверия. Система ищет issuing centre (центр, который выдал сертификат) в хранилищах сертификатов: личном, промежуточном и доверенных корневых центров. Если промежуточный сертификат не найден в файле, система пытается загрузить его из сети по ссылкам AIA (Authority Information Access) или из локального кэша. Цель — получить непрерывную цепочку, где каждый сертификат подписан следующим, пока не будет достигнут корневой сертификат, присутствующий в доверенном хранилище Windows.

Проверка сертификатов

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

• Срок действия: текущая системная дата должна находиться между полями notBefore и notAfter;
• Отзыв: система проверяет, не отозван ли сертификат, используя списки отзыва (CRL) или протокол OCSP. Если сервер отзыва недоступен, результат зависит от политики проверки отзыва (может быть soft‑fail или hard‑fail);
• Назначение (EKU): в расширении Enhanced Key Usage должен присутствовать OID 1.3.6.1.5.5.7.3.3, который указывает на разрешение подписи кода;
• Доверие к корню: корневой сертификат должен находиться в одном из доверенных хранилищ (Trusted Root Certification Authorities) и быть помечен как доверенный для проверки кода.

Если любой из пунктов не выполняется, цепочка считается нарушенной.

Проверка временной метки

Если в подписи присутствует временная метка, система выполняет аналогичную проверку для сертификата TSA:

• проверяет срок действия сертификата TSA на момент timestamp;
• проверяет отзыв этого сертификата;
• убеждается, что у TSA есть EKU для timestamping (1.3.6.1.5.5.7.3.8) или общий EKU для подписи;
• проверяет, что корень TSA доверен.

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

Ограничения и факторы, влияющие на результат

• Доступ к серверам отзыва: если машина не может связаться с CRL/OCSP, проверка может завершиться с ошибкой или принять решение согласно настроенной политике (по умолчанию Windows использует soft‑fail для обновления через фоновую задачу).
• Политика проверки отзыва: можно включить строгую проверку (hard‑fail) через групповую политику или реестр, что приведёт к отклонению подписи при недоступности сервера отзыва.
• Наличие промежуточных сертификатов: если издатель не включает промежуточный сертификат в файл, а он отсутствует в локальном кэше и недоступен по сети, цепочка прерывается.
• Доверие к корню: корневые центры должны быть предварительно установлены в доверенное хранилище. В корпоративных средах иногда добавляются частные корни, которые необходимо распространить на все конечные машины.
• Подпись без временной метки: такая подпись становится недействительной сразу после истечения срока сертификата издателя, что может привести к внезапным сбоям в работе подписанных продуктов.

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

• Подпись с истёкшим сертификатом без timestamp: решение — всегда добавлять timestamp при подписи и обновлять сертификат до окончания срока.
• Отсутствие EKU для подписи кода: при приобретении сертификата уточняйте, что он включает OID 1.3.6.1.5.5.7.3.3.
• Прерывание цепочки из‑за missing intermediate: включайте все промежуточные сертификаты в файл при помощи параметра /ac при signtool, либо распространяйте их через групповые политики.
• Отзыв сертификата: следите за датой окончания и своевременно обновляйте ключи; при компрометации сразу отзывайте старый сертификат и публикуйте новый.
• Недоверенный корень TSA: используйте timestamp‑службы от общедоступных и доверенных центров (например, timestamp.digicert.com, timestamp.sectigo.com) либо собственный TSA, корень которого находится в доверенном хранилище.

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

Для ручной проверки подписи можно воспользоваться утилитой signtool, которая входит в Windows SDK. Ниже описан порядок действий без использования дополнительных программ.

1. Откройте командную строку с правами администратора.
2. Выполните команду: signtool verify /pa /v <путь_к_файлу>
3. Ознакомьтесь с выводом:
• Если строка Successfully verified присутствует — подпись считается доверенной.
• Сообщения о цепочке (Chain indexing) покажут, где произошло прерывание, если оно есть.
• Информация о timestamp указывает, была ли проверена временная метка и считается ли она валидной.
• Уведомления об отзыве (revocation) сообщат, если какой‑то сертификат в цепочке отозван.
4. При необходимости повторите проверку с параметром /kp для включения строгой проверки отзыва (hard‑fail).

Если проверка не проходит, сосредоточьтесь на первом сообщении об ошибке: оно обычно указывает на конкретный этап (например, « certificate is not in the trusted root store» или « revocation check failed»). Это позволяет быстро локализовать проблему и принять соответствующее действие (обновить хранилище, добавить промежуточный сертификат, проверить доступ к серверу отзыва и т.д.).

Главный принцип и следующие шаги

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

Чтобы обеспечить надёжную работу подписанных продуктов, рекомендуется:

• Всегда применять timestamp при подписи;
• Обновлять сертификаты заранее до окончания срока;
• Включать все необходимые промежуточные сертификаты в пакет подписи;
• Распространять доверенные корни и промежуточные центры в корпоративной среде через групповые политики;
• Периодически проверять ключевые файлы при помощи signtool, особенно после изменений в инфраструктуре PKI или после обновления Windows.

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