Как проверить цифровую подпись файла перед запуском: пошаговое руководство для Windows, macOS и Linux

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

Зачем проверять цифровую подпись

Любой исполняемый файл (.exe, .msi, .dll, .app, .dmg, .deb, .rpm, .apk, скрипты) может быть подменён злоумышленником: встроен вредоносный код, заменён установщик, изменена конфигурация. Антивирус может не сработать на новой или целевой атаке. Цифровая подпись решает другую задачу — подтверждает авторство и целостность:

• Авторство: файл подписан сертификатом, выданным удостоверяющим центром (CA) после проверки организации. Вы видите настоящее имя компании, а не случайную строку.
• Целостность: любой битовый изменение файла после подписания делает подпись недействительной.
• Временная метка (timestamp): показывает, когда файл был подписан. Если сертификат истёк, но подпись имеет валидную временную метку — файл считается доверенным на момент подписания.

Проверка подписи не заменяет антивирус и не гарантирует отсутствие уязвимостей в самом коде. Она подтверждает: «этот конкретный файл вышел из рук этой конкретной организации и не менялся по пути к вам».

Как работает цифровая подпись (кратко, для понимания критериев)

Разработчик получает сертификат подписания кода (Code Signing Certificate) у публичного CA (Sectigo, DigiCert, GlobalSign и др.). CA проверяет юридическое лицо: название, адрес, телефон, домен. Для EV-сертификатов (Extended Validation) проверка строже — требуется физическое наличие, нотариальные документы, звонок в компанию.

При подписании создаётся хеш файла (SHA-256 стандарт), который шифруется закрытым ключом разработчика. В файл встраивается подпись + цепочка сертификатов до корневого CA. При проверке система:

1. Вычисляет хеш файла.
2. Расшифровывает подпись открытым ключом из сертификата.
3. Сравнивает хеши — совпали? Файл цел.
4. Проверяет цепочку доверия: сертификат разработчика → промежуточный CA → корневой CA, который есть в хранилище доверенных корневых центров ОС.
5. Проверяет срок действия сертификата и наличие временной метки.
6. Проверяет отзыв (CRL/OCSP) — не отозван ли сертификат до срока.

Если хоть один этап проваливается — подпись недействительна.

Проверка в Windows: встроенные способы

Свойства файла (GUI) — самый быстрый способ

1. Нажмите правой кнопкой на файл → Свойства.
2. Перейдите на вкладку Цифровые подписи (Digital Signatures). Если вкладки нет — файл не подписан.
3. В списке выберите подпись (обычно одна) → нажмите Сведения (Details).
4. В открывшемся окне посмотрите строку Сведения о подписи (Signature Information). Должно быть: «Эта цифровая подпись действительна» (This digital signature is OK).
5. Нажмите Просмотр сертификата (View Certificate) → вкладка Сведения (Details). Проверьте:
6. Субъект (Subject): CN = имя организации (например, «Microsoft Corporation», «Oracle Corporation», «JetBrains s.r.o.»).
7. Издатель (Issuer): известный CA (DigiCert, Sectigo, GlobalSign, Microsoft Root Certificate Authority и т.д.).
8. Действителен с / по: даты в разумных пределах.
9. Отпечаток (Thumbprint): SHA-1 или SHA-256 хеш сертификата — можно сверить с опубликованным разработчиком.

Важно: Вкладка «Цифровые подписи» показывает только подписи, встроенные в файл (Authenticode). Подписи каталогов (.cat) или подписи драйверов в системном хранилище там не видны.

PowerShell: Get-AuthenticodeSignature — для автоматизации и пакетной проверки

Откройте PowerShell (не обязательно от администратора) и выполните:

Get-AuthenticodeSignature -FilePath «C:\путь\к\файлу.exe» | Format-List *

Ключевые поля результата:

• Status: Valid (действительна), Invalid (недействительна), UnknownError, NotSigned (не подписан), HashMismatch (хеш не совпал — файл изменён).
• StatusMessage: текстовое описание (например, «Хеш файла не совпадает с хешем в подписи»).
• SignerCertificate: объект сертификата — можно извлечь Subject, Issuer, NotAfter, Thumbprint.
• TimeStamperCertificate: сертификат сервера временных меток (если есть).
• Path: путь к файлу.

Пример проверки нескольких файлов:

Get-ChildItem «C:\Downloads\*.exe» | ForEach-Object {
$sig = Get-AuthenticodeSignature $_.FullName
[PSCustomObject]@{
File = $_.Name
Status = $sig.Status
Signer = $sig.SignerCertificate.Subject
Issuer = $sig.SignerCertificate.Issuer
ValidTo = $sig.SignerCertificate.NotAfter
}
} | Format-Table -AutoSize

Signtool.exe (Windows SDK) — для глубокой диагностики

Если установлен Windows SDK (или Visual Studio), доступен signtool.exe. Он показывает полную цепочку, временную метку, отзыв:

signtool verify /pa /v «C:\путь\к\файлу.exe»

Ключи: /pa — использовать политику Authenticode по умолчанию (проверка отзыва включена), /v — подробный вывод. Вывод покажет каждый сертификат цепочки, сроки, CRL/OCSP статус, наличие timestamp.

Проверка подписи каталога (.cat) и драйверов

Драйверы и системные файлы часто подписаны не встроенно, а через каталог безопасности (.cat). Проверить их можно командой:

signtool verify /pa /v /c «C:\путь\к\файлу.cat» «C:\путь\к\драйверу.sys»

Или через PowerShell:

Get-AppLockerFileInformation -Path «C:\Windows\System32\drivers\example.sys»

Проверка в macOS: codesign и spctl

Terminal: codesign — основной инструмент

Откройте Терминал и выполните:

codesign -dv —verbose=4 /путь/к/файлу.app

Для исполняемых файлов внутри бандла:

codesign -dv —verbose=4 /путь/к/файлу.app/Contents/MacOS/исполняемый_файл

Ключевой вывод:

• Authority= — цепочка: Developer ID Application: Имя Организации (Team ID) → Developer ID Certification Authority → Apple Root CA.
• TeamIdentifier= — уникальный ID команды разработчика в Apple Developer Program (например, 7AGZNQ2S2T для Microsoft). Можно сверить на сайте разработчика.
• Signed Time= — дата подписания.
• Timestamp= — есть ли временная метка (обычно есть у notarized приложений).
• Sealed Resources= — версия правил ресурсов (rules=vvvv…).

Если выводит code object is not signed at all — файл не подписан.

Проверка нотаризации (notarization) — spctl

Начиная с macOS 10.15 (Catalina), приложения, распространяемые вне Mac App Store, должны быть нотаризованы Apple. Проверка:

spctl -a -vvv -t install /путь/к/файлу.app

Результат accepted с source=Notarized Developer ID — приложение прошло автоматическую проверку Apple на вредоносный код и подписано валидным Developer ID. source=Developer ID без нотаризации — старый формат, на новых macOS может не запуститься без снятия карантина (xattr -d com.apple.quarantine).

Проверка .dmg и .pkg установщиков

Для .dmg:

codesign -dv —verbose=4 /Volumes/Имя_образа/Приложение.app

Для .pkg (проверка пакета установщика):

pkgutil —check-signature /путь/к/установщику.pkg

Вывод покажет цепочку сертификатов и статус: valid или ошибки.

Проверка в Linux: gpg, rpm, dpkg, AppImage

В Linux нет единого хранилища подписей как в Windows/macOS. Подход зависит от формата пакета и способа распространения.

РПМ-пакеты (RHEL, Fedora, openSUSE): rpm —checksig

rpm —checksig пакет.rpm

Результат покажет: md5 OK, sha256 OK, gpg OK (или gpg NOT OK). Для импорта ключей разработчика:

rpm —import https://developer.example.com/key.gpg

Многие репозитории (EPEL, RPM Fusion, официальные Fedora/RHEL) подписывают пакеты своими ключами, которые уже в системе или подключаются при добавлении репо.

DEB-пакеты (Debian, Ubuntu): dpkg-sig / gpg —verify

Установленные пакеты проверяются через apt (подписи репозитория). Для отдельного .deb файла:

dpkg-sig —verify пакет.deb
# или вручную:
ar x пакет.deb
gpg —verify control.tar.gz.sig control.tar.gz

Ключи разработчиков часто лежат в /usr/share/keyrings/ или добавляются через apt-key (устарело) / signed-by в sources.list.

AppImage: встроенная подпись (AppImageSign)

AppImage может содержать встроенную GPG-подпись. Проверка:

./приложение.AppImage —appimage-signature
# или
gpg —verify приложение.AppImage.asc приложение.AppImage

Многие проекты публикуют .asc файлы рядом с релизом на GitHub/GitLab. Ключ разработчика нужно получить из надёжного источника (официальный сайт, KEYBASE, WKD).

Flatpak и Snap: подписи репозиториев

Flatpak: подписи проверяются автоматически при установке из репозитория (Flathub использует GPG). Ручная проверка:

flatpak verify —file=приложение.flatpak

Snap: подписи проверяются snapd при установке. Snap Store подписывает все пакеты. Ручная проверка не предусмотрена пользователю — модель доверия к магазину.

Произвольные бинарники и скрипты: GPG detached signature

Если разработчик распространяет файл + .sig/.asc отдельно:

gpg —verify файл.sig файл
# или
gpg —verify файл.asc файл

Нужен публичный ключ разработчика (gpg —import ключ.asc или gpg —keyserver keys.openpgp.org —recv-keys KEYID). Всегда проверяйте отпечаток ключа (fingerprint) через независимый канал (сайт проекта, GitHub verified badge, личная встреча).

Сторонние кроссплатформенные инструменты

Инструмент	Платформы	Что проверяет	Особенности
VirusTotal (веб/CLI)	Любая (браузер)	Подпись Authenticode, кодовые сертификаты, репутация, антивирусные движки	Загружает файл на сервер — не для конфиденциальных данных. Показывает историю подписей, отозванные сертификаты, комментарии сообщества.
Sigcheck (Sysinternals)	Windows	Authenticode, цепочка сертификатов, timestamp, OTSP/CRL, хеши (SHA1/256/512), версию файла	Консольная утилита, ключ -i для полной инфы, -vt для отправки на VT. Не требует установки.
osslsigncode	Linux, macOS, Windows	Проверка и создание Authenticode подписей (PE файлы)	OpenSource альтернатива signtool. Полезна на Linux для проверки .exe/.dll/.msi.
codesign / spctl	macOS	Нативные подписи, нотаризация, hardened runtime	Встроены в систему.
gpgtar / gpg	Кроссплатформенно	OpenPGP подписи (AppImage, исходники, произвольные файлы)	Стандарт де-факто для Linux-сообщества и открытого ПО.

Рекомендация: Для Windows रखните sigcheck.exe в PATH — он даёт больше деталей, чем вкладка свойств, и работает из скриптов. Для кроссплатформенной проверки PE-файлов на Linux/macOS — osslsigncode verify.

Как интерпретировать результат проверки: чек-лист

После проверки у вас на руках данные. Что именно смотреть и какие решения принимать:

• Статус «Valid» / «Действительна» / «accepted»: Подпись математически верна, цепочка доверия построена до доверенного корневого CA, сертификат не отозван, срок действия в норме (или есть валидная временная метка). → Файл подлинный и цел.
• Имя субъекта (Subject CN / Organization): Соответствует ли заявленному разработчику? «Microsoft Corporation» — ок. «Microsoft Corp.» (с точкой) или «Microsft» — подделка. Сравнивайте с официальным сайтом.
• Издатель (Issuer): Известный публичный CA (DigiCert, Sectigo, GlobalSign, Entrust, Apple, Microsoft Root CA). Неизвестный или самоподписанный (Self-signed) — красный флаг. Самоподписанные сертификаты используются для тестов, внутренних инструментов, вредоносов.
• Тип сертификата: OV (Organization Validated) — стандарт. EV (Extended Validation) — строже проверка, выдаётся на USB-токен, требует физического присутствия. EV даёт больше доверия, но OV тоже валиден. В Windows EV-сертификаты получают мгновенную репутацию SmartScreen.
• Временная метка (Timestamp): Есть? Если сертификат истёк, но есть timestamp от доверенного TSA (Time Stamping Authority) — подпись считается валидной на момент подписания. Нет timestamp и сертификат просрочен — подпись недействительна сейчас, но файл мог быть подписан легально раньше. Проверяйте дату подписания.
• Отзыв (Revocation): Статус CRL/OCSP — «Good» / «Valid». Если «Revoked» — сертификат скомпрометирован или отозван разработчиком. Файл может быть легальным (подписан до отзыва), но доверие снижено. Если при проверке ошибка сети (недоступен CRL/OCSP) — Windows по умолчанию считает подпись валидной (soft-fail). Можно включить строгий режим через политику.
• Хеш файла: Если есть опубликованный SHA-256 на сайте разработчика — сверьте. Get-FileHash -Algorithm SHA256 файл.exe (PowerShell) или sha256sum файл (Linux/macOS).

Типичные ошибки и ловушки

• «Файл подписан, значит безопасен» — нет. Подпись подтверждает авторство и целостность, а не отсутствие багов, бэкдоров или вредоносной функциональности, заложенной самим разработчиком (supply chain attack). Пример: компрометация сервера сборки SolarWinds — файлы были подписаны валидным сертификатом.
• Игнорирование отсутствия подписи — многие легатимальные утилиты с открытым кодом (NirSoft, Sysinternals до покупки MS, мелкие проекты на GitHub) не подписаны. Это не значит «вирус», но значит: вы не можете криптографически подтвердить происхождение. Решение: скачивайте только с официального сайта/репозитория, сверяйте хеши, изучайте код/репутацию.
• Проверка только имени файла или иконки — злоумышленники копируют имена (chrome_setup.exe, update.exe) и иконки. Только цифровая подпись и хеш дают гарантию.
• Проверка подписи установщика, но не встроенных компонентов — .msi/.exe может быть подписан, но скачивать и запускать неподписанные .dll/.exe из временной папки. Используйте мониторинг процессов (Process Monitor, Procmon) или изолированную среду (песочницу, VM) для анализа поведения.
• Доверие к сертификату только потому, что он «зеленый» в браузере/проводнике — UI может показывать упрощённый статус. Всегда смотрите детали: Subject, Issuer, Validity, Thumbprint.
• Использование устаревших алгоритмов — SHA-1 подписи считаются небезопасными с 2017 года. Windows 10/11 помечают их как слабые. Современный стандарт — SHA-256 / SHA-384. Если видите SHA-1 в 2024+ году — основание для подозрения.

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

Ситуация	Действия
Скачали установщик популярной программы с официального сайта (HTTPS, верный домен)	Проверьте подпись (вкладка свойств или PowerShell). Сверьте Subject CN с названием компании. Если валидно — запускайте. Хеш сверяйте опционально.
Скачали с зеркала / стороннего сайта / файлообменника	Обязательно проверьте подпись + хеш (SHA-256) с официального сайта разработчика. Нет подписи — не запускайте, если не доверяете источнику на 100% и не можете проверить код.
Получили файл по email / мессенджер от коллеги / партнёра	Проверьте подпись. Если подписан валидным сертификатом известной организации — ок. Если нет — уточните у отправителя источник, попросите хеш. Не запускайте «на слово».
Файл подписан, но издатель — неизвестная организация / самоподписанный	Высокий риск. Это может быть внутренний инструмент компании, тестовая сборка, open source проект без бюджета на сертификат ($200-600/год), или вредонос. Решение: изолированная среда (VM, песочница), анализ поведения, поиск репутации по хешу на VirusTotal.
Подпись недействительна (HashMismatch / Invalid)	Файл изменён после подписания. Повреждён при скачивании, заражён, или разработчик переподписал неверно. Не запускайте. Скачайте заново с официального источника.
Сертификат истёк, нет временной метки	Подпись недействительна сейчас. Файл мог быть легальным на момент выпуска. Проверьте дату подписания (Signing Time). Если файл старый (драйвер 2015 года) — можно принять риск в изолированной среде. Для нового файла — признак проблемы.
Open Source утилита с GitHub Releases без подписи	Проверьте: релиз опубликован в официальном репозитории (проверьте URL: github.com/owner/repo/releases). Сверьте SHA-256 из release notes / assets. Изучите коммиты и репутацию автора. В идеале — соберите из исходников сами.
Драйвер / системный компонент	Проверяйте через signtool / Get-AuthenticodeSignature. Драйверы ядра (kernel-mode) на Windows 10/11 должны иметь EV-сертификат и подпись Microsoft (WHQL / HLK) для загрузки без тестового режима. Обычный OV — не загрузится.

Практические рекомендации: следующий шаг

1. Сделайте проверку привычкой: перед запуском любого нового .exe/.msi/.app/.dmg/.AppImage — 10 секунд на вкладку «Цифровые подписи» или команду sigcheck -i файл / codesign -dv файл.
2. Ведите локальную базу доверенных отпечатков (Thumbprints): для критичного ПО (банкинг, VPN, админ-инструменты) сохраните SHA-1/SHA-256 отпечатки сертификатов разработчиков. При обновлении сверяйте — сменился отпечаток? Это повод проверить, не скомпрометирован ли сертификат.
3. Используйте песочницу для неподписанного / подозрительного: Windows Sandbox (Pro/Enterprise), VMware/VirtualBox, Firejail (Linux), отдельная тестовая машина. Не запускайте «посмотреть» на основной системе.
4. Настройте политику выполнения (Windows): AppLocker / WDAC (Windows Defender Application Control) могут блокировать запуск неподписанных или неподписанных доверенными издателями файлов. Это корпоративный уровень, но доступен и про-юзерам через Local Security Policy.
5. Обновляйте хранилище корневых сертификатов: Windows Update делает это автоматически. На Linux — пакет ca-certificates обновляется с системой. Устаревшие корневые CA приведут к ложным «недействительным» для валидных новых сертификатов.
6. Проверяйте хеш (SHA-256) для критических файлов: даже при валидной подписи. Supply chain атаки (как у 3CX, SolarWinds) давали валидные подписи. Хеш с официального сайта / GitHub Releases / анонса — вторая линия обороны.

FAQ: частые вопросы

В: Файл подписан, но SmartScreen ругается «Неизвестный издатель». Это нормально?

О: Да. SmartScreen оценивает репутацию: возраст сертификата, количество скачиваний, репутацию IP/домена. Новый EV-сертификат или малоизвестная программа будут вызывать предупреждение до накопления репутации. Проверьте детали подписи вручную — если Subject и Issuer верны, подпись валидна, timestamp есть — файл подлинный. Репутация наберётся со временем.

В: Можно ли подделать цифровую подпись?

О: Математически — нет, без закрытого ключа. Но можно: украсть ключ у разработчика (компрометация build-сервера, фишинг), получить сертификат на подставную компанию (редко, CA проверяют), использовать самоподписанный сертификат и обмануть пользователя именем «Microsoft Corporation» в Subject (UI показывает имя, но Issuer будет самоподписанным). Всегда проверяйте Issuer и цепочку доверия.

В: Почему у файла две вкладки «Цифровые подписи» или несколько подписей в списке?

О: Можно добавить несколько подписей (co-signing): например, разработчик + дистрибьютор, или повторная подпись при ребрендинге. PowerShell Get-AuthenticodeSignature показывает только первую. signtool verify /v покажет все. Проверяйте каждую.

В: Что такое «каталог безопасности» (.cat) и почему у драйвера нет вкладки подписи?

О: Драйверы и системные файлы часто не подписываются встроенно (Authenticode), а через каталог .cat, который устанавливается в системное хранилище. Подпись проверяется при установке/загрузке драйвера. Ручная проверка — через signtool verify /c файл.cat драйвер.sys.

В: Стоит ли проверять подписи скриптов (.ps1, .sh, .py, .bat)?

О: Да. PowerShell поддерживает подписание скриптов (Set-AuthenticodeSignature). Политика ExecutionPolicy (AllSigned, RemoteSigned) может требовать валидную подпись. Bash/Python/BAT — нет нативной поддержки, используйте GPG detached signatures или хеши.

Важно: Материал носит информационный характер. Проверка цифровой подписи — важный, но не единственный элемент безопасности. Она не защищает от уязвимостей в легатимном коде, supply chain атак с валидными сертификатами, социальной инженерии или нулевых дней (zero-day). Для критических систем и обработки чувствительных данных используйте многослойную защиту: изоляцию, мониторинг поведения, актуальные обновления ОС и ПО, консультации с ИБ-специалистами.

Резюме: главный принцип

Цифровая подпись — это паспорт файла. Она отвечает на вопросы «кто сделал?» и «меняли ли после?». Проверка занимает секунды встроенными средствами любой ОС. Алгоритм прост: есть подпись → валидна ли → имя издателя совпадает с ожидаемым → цепочка доверия к известному CA → есть timestamp → сертификат не отозван. Если хоть один пункт «нет» — риск растёт. Для неподписанных файлов — только хеш с официального источника, репутация проекта, песочница или сборка из исходников. Никакой инструмент не даёт 100% гарантии, но игнорирование подписи — гарантированный путь запустить чужой код.