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

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

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

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

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

Проблема в том, что сама по себе подпись ничего не доказывает. Любой человек может сгенерировать собственный ключ и сертификат с любым именем внутри. Поэтому возникает вопрос: кому мы вообще верим? Ответ даёт модель цепочки доверия (chain of trust). Сертификат подписывающего разработчика выпущен промежуточным центром сертификации, тот, в свою очередь, заверен корневым сертификатом. Корневые сертификаты предустановлены в Windows и хранятся в системных хранилищах сертификатов. Если вся цепочка от листового сертификата до корня сходится математически и каждый её элемент действителен, имя на подписи получает смысл.

Аналогия простая: подпись на документе ценна не росчерком, а тем, кто может подтвердить личность подписавшего. Цепочка сертификатов — это и есть подтверждение личности, оформленное криптографически.

Из чего состоит подпись Authenticode

Подписанный файл содержит несколько связанных элементов, и полезно понимать их роли:

• Хеш содержимого. При подписании вычисляется криптографический хеш файла. Он шифруется закрытым ключом разработчика и становится электронной подписью. При проверке Windows заново считает хеш и сравнивает его с расшифрованным значением из подписи — так выявляется любое изменение байтов файла.
• Сертификат подписи (leaf certificate). Сертификат издателя ПО, выпущенный центром сертификации. В нём указаны субъект, срок действия, назначение (например, Code Signing) и открытый ключ.
• Цепочка промежуточных сертификатов. Обычно подписывающий сертификат выпущен не напрямую корнем, а через один или несколько промежуточных центров. Промежуточные сертификаты часто вкладываются в саму подпись, чтобы проверяющая сторона могла построить путь даже без доступа к сети.
• Атрибуты и метки времени. Отдельный блок, который позволяет подписи оставаться действительной после истечения срока самого сертификата — об этом ниже, потому что это одна из самых частых причин путаницы.

Всё это упаковано в структуру SignedData по стандарту PKCS#7/CMS и встраивается в файл либо хранится рядом в каталоге подписей (catalog file), что типично для системных компонентов Windows.

Как Windows строит цепочку доверия: пошаговый механизм

Проверку выполняет системный механизм проверки пути сертификации (в Windows это компоненты CryptoAPI, в частности функции семейства CertGetCertificateChain). Логика выглядит так:

1. Извлечение подписи. Система читает блок подписи из файла или находит соответствующую запись в каталоге подписей.
2. Проверка хеша. Пересчитывается хеш содержимого и сравнивается со значением в подписи. Несовпадение означает, что файл изменён после подписания, — дальнейшие шаги теряют смысл.
3. Построение пути. Для сертификата подписи система ищет сертификат издателя: сначала среди вложенных в подпись, затем в локальных хранилищах («Промежуточные центры сертификации»). Так поднимается вверх до сертификата, который самоподписан и присутствует в хранилище «Доверенные корневые центры сертификации».
4. Криптографическая сверка каждого звена. Каждый сертификат цепочки проверяется подписью вышестоящего: подпись промежуточного должна корректно расшифровываться открытым ключом корня, подпись листового — открытым ключом промежуточного.
5. Проверка параметров каждого сертификата. Срок действия, назначение (должно допускать подпись кода), ограничения имени, политики применения, ограничения длины пути (path length constraints), если они заданы.
6. Проверка статуса отзыва. Для каждого звена запрашивается статус: по CRL (список отозванных сертификатов) или по протоколу OCSP. Если сертификат отозван, цепочка признаётся недействительной целиком.
7. Сведение результата. Формируется итоговый статус цепочки и подписи, который видят проводник, браузер при загрузке, SmartScreen и другие потребители.

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

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

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

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

Отсюда практические следствия:

• Подпись без метки времени «умирает» вместе с сертификатом: после истечения срока Windows начнёт показывать предупреждения, хотя в день выпуска всё было в порядке.
• Метка времени сама является подписанной структурой и тоже имеет свою цепочку сертификатов, которую система проверяет отдельно.
• Отзыв сертификата учитывается иначе: если сертификат отозван, подпись с меткой времени обычно признаётся недействительной, поскольку отзыв означает компрометацию ключа или нарушение правил издателем.

Что именно делает подпись недействительной: типичные причины

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

}

Причина	Что происходит	Типичный признак для пользователя
Файл изменён после подписания	Пересчитанный хеш не совпадает с подписанным	«Цифровая подпись недействительна»; частый признак заражения или пересборки файла
Нет цепочки до доверенного корня	Промежуточные сертификаты отсутствуют, корень неизвестен системе	«Не удаётся проверить подпись» или «издатель неизвестен»
Истёк срок сертификата без метки времени	На дату проверки сертификат недействителен	Подпись работала раньше, сейчас — предупреждение об истечении
Сертификат отозван	CRL/OCSP сообщает об отзыве любого звена цепочки	Явное сообщение об отзыве; файл лучше не запускать
Неверное назначение сертификата	Сертификат выпущен, например, для TLS, а не для подписи кода	Подпись есть, но не проходит проверку назначения EKU
Повреждена структура подписи	Блок CMS некорректен или усечён	Подпись отсутствует или не читается вовсе

Отдельно стоит сказать про отсутствие подписи как таковое. Это не ошибка проверки, а её отсутствие: неподписанный файл не проходит ни одну ступень модели доверия, и современные механизмы Windows (SmartScreen, политика AppLocker, требования драйверов ядра) относятся к нему заметно жёстче, чем к файлу с валидной подписью.

Где хранятся доверенные корни и как это устроено в системе

Доверие в Windows начинается с хранилища «Доверенные корневые центры сертификации» (Trusted Root Certification Authorities). Корни туда попадают двумя путями: предустановлены вместе с системой и обновлениями либо добавлены администратором или пользователем вручную. Второй путь — потенциально опасный: добавленный корень получает возможность выпускать сертификаты, которые система будет считать доверенными для всех целей, поэтому произвольное добавление корней — распространённая ошибка безопасности.

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

Посмотреть хранилища можно самостоятельно: запустите certmgr.msc для пользовательских хранилищ или certlm.msc для машинных (требуются права администратора). Разделы «Доверенные корневые центры сертификации» и «Промежуточные центры сертификации» — это те самые два уровня, между которыми строится путь.

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

Для разовой проверки достаточно средств самой системы:

1. Щёлкните файл правой кнопкой, откройте «Свойства», перейдите на вкладку «Цифровые подписи».
2. Выберите подпись в списке и нажмите «Сведения».
3. Обратите внимание на строку статуса: «Эта цифровая подпись действительна» — хороший знак; любые другие формулировки требуют внимания.
4. Нажмите «Просмотреть сертификат» и изучите путь сертификации: видно всю иерархию от вашего файла до корня, а также статус каждого звена.

Для более детального анализа удобна утилита командной строки Signtool из состава Windows SDK. Команда вида signtool verify /pa /v имя_файла выводит подробный отчёт: используемые политики проверки, построенную цепочку, результат проверки отзыва и конкретные ошибки, если они есть. Ключ /pa включает проверку по политике Authenticode по умолчанию, /v — подробный режим. Такой отчёт особенно полезен разработчикам: он показывает, вложены ли промежуточные сертификаты в подпись и проставлена ли метка времени.

Ещё один инструмент — certutil: команда certutil -verify -urlfetch файл_сертификата.cer проверяет цепочку отдельного сертификата, включая загрузку CRL и OCSP-ответов по сети. Это помогает понять, доступен ли сервер отзыва и какой именно статус возвращается.

Ограничения модели: что проверка цепочки не гарантирует

Полезно трезво понимать границы механизма, чтобы не переоценивать зелёную галочку:

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

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

Практические рекомендации для разных ситуаций

Если вы обычный пользователь и столкнулись с предупреждением о подписи при установке программы:

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

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

1. Запрашивайте сертификат именно с назначением Code Signing у аккредитованного центра сертификации.
2. При подписании обязательно используйте метку времени — это сохранит валидность подписи после истечения сертификата.
3. Включайте промежуточные сертификаты в подпись (в signtool это делается автоматически при наличии их в хранилище), чтобы проверка работала на машинах без этих сертификатов.
4. Перед релизом проверяйте результат командой signtool verify на чистой виртуальной машине без ваших локальных сертификатов — так вы увидите то же, что увидит пользователь.
5. Храните закрытый ключ защищённо: аппаратные токены и облачные службы подписания существенно снижают риск компрометации и последующего отзыва.

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

Почему подпись была действительной вчера, а сегодня система её не принимает?

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

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

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

Чем отличается «неподписанный файл» от «недействительной подписи»?

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

Зачем нужна метка времени, если сертификат всё равно можно отозвать?

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

Что запомнить и что делать дальше

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

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

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