Какие данные сертификата подтверждают личность издателя файла: практическое руководство

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

Структура идентификации в сертификате X.509

Цифровой сертификат — это структура по стандарту X.509. Для идентификации издателя ключевыми являются поля в разделе Subject (Субъект) и расширение Subject Alternative Name (SAN). Остальные поля (серийный номер, сроки действия, алгоритм подписи, расширения ключа) важны для криптографической валидности, но не несут сведений о юридическом лице.

Поле Subject (DN — Distinguished Name)

Subject представляет собой набор атрибутов (RDN — Relative Distinguished Names). На практике для идентификации издателя программного обеспечения используются следующие атрибуты:

• CN (Common Name) — обычное имя. Для сертификатов подписи кода (Code Signing) это название организации или продукта. Пример: CN=ООО «Ромашка».
• O (Organization) — полное юридическое название организации. Должно совпадать с регистрационными документами. Пример: O=Общество с ограниченной ответственностью «Ромашка».
• OU (Organizational Unit) — подразделение. Часто указывает отдел разработки или бренд. Пример: OU=Отдел безопасности.
• L (Locality), S (State/Province), C (Country) — город, регион, код страны (ISO 3166). Пример: L=Москва, S=Москва, C=RU.
• Email — контактный адрес организации (не персональный разработчика).

Важно: порядок атрибутов в DN нестандартизирован. Разные УЦ (уполномоченные центры) могут выводить их в разной последовательности. Сравнивать нужно значения конкретных атрибутов, а не строку целиком.

Расширение Subject Alternative Name (SAN)

SAN — современный и более гибкий способ указания идентификаторов. Для Code Signing сертификатов в SAN могут присутствовать:

• directoryName — альтернативное представление DN (дублирует Subject).
• rfc822Name — email организации.
• uniformResourceIdentifier — URL официального сайта издателя.
• otherName (Microsoft UPN / SID) — идентификаторы в экосистеме Windows (например, SID издателя для SmartScreen).

Наличие URI с официальным доменом организации в SAN — сильный сигнал легитимности, так как УЦ проверяет контроль над доменом при выдаче.

Уровни валидации: EV, OV, DV — чем отличаются для идентификации

Уровень валидации определяет, насколько тщательно УЦ проверил личность заявителя перед выпуском сертификата. Для подписи кода (Code Signing) существуют два основных уровня: OV (Organization Validation) и EV (Extended Validation). DV (Domain Validation) для подписи исполняемых файлов не выдаётся — браузеры и ОС не доверяют таким сертификатам для кода.

Характеристика	OV (Organization Validation)	EV (Extended Validation)
Проверка юридического лица	Да: реестры (ЕГРЮЛ/ЕГРИП), телефон, домен	Да: усиленная — устав, доверенность, callback на корп. телефон, проверка физического адреса
Проверка домена	Да (email/DNS/HTTP)	Да (строже)
Хранение закрытого ключа	Программное (файл .pfx/.p12) или HSM	Только аппаратное: HSM или токен (FIPS 140-2 Level 2+)
Отображение в Windows SmartScreen	Репутация накапливается со временем	Мгновенная репутация «Known publisher», зелёная полоса в SmartScreen
Поле Subject	Содержит O, CN, L, S, C	Содержит O, CN, L, S, C + обязательно serialNumber (ИНН/ОГРН) и jurisdictionCountry/jurisdictionLocality
Срок выдачи	1–3 дня	3–10 дней
Цена (ориентир)	~15–40 тыс. руб./год	~60–120 тыс. руб./год

Практический вывод: если файл подписан EV-сертификатом, вы видите проверенное юридическое лицо с мгновенной репутацией. Если OV — лицо проверено, но репутация накапливается; при первом запуске SmartScreen может предупредить «Неизвестный издатель» даже при валидном OV-сертификате. Это не ошибка сертификата, а механизм репутации.

Ключевые поля для ручной проверки идентичности

Откройте свойства файла → вкладка «Цифровые подписи» → выберите подпись → «Сведения» → «Просмотреть сертификат» → вкладка «Состав». На что смотреть:

1. Subject → O (Organization) — полное юридическое название. Сравните с сайтом компании, реестром ЕГРЮЛ/ЕГРИП, договором.
2. Subject → CN (Common Name) — часто совпадает с O или содержит бренд. Не должно быть обобщённым вроде «Developer» или «Test Certificate».
3. Subject → serialNumber — для EV-сертификатов содержит ИНН (РФ) или регистрационный номер в другой юрисдикции. Проверить можно на сайте ФНС или в открытых реестрах.
4. Subject → jurisdictionCountry / jurisdictionLocality — код страны и регион регистрации юридического лица (только EV).
5. SAN → uniformResourceIdentifier — официальный сайт. Откройте, убедитесь, что домен принадлежит той же организации.
6. Issuer (Издатель сертификата) — название УЦ (например, «GlobalSign CodeSigning CA — G3», «Sectigo RSA Code Signing CA», «DigiCert EV Code Signing CA»). УЦ должен быть в доверенных корневых хранилищах Microsoft / Apple / Mozilla.
7. Valid from / Valid to — срок действия. Подпись действительна, если момент подписания (timestamp) попадает в срок действия сертификата.
8. Timestamp (метка времени) — отдельная подпись от TSA (Time Stamping Authority). Если есть валидный timestamp, подпись остаётся доверенной после истечения сертификата. Без timestamp — подпись становится недействительной после expiry сертификата.

Цепочка доверия: почему валидный сертификат может не доверяться

Сертификат файла (leaf) подписан промежуточным УЦ, тот — корневым. Корневой сертификат должен находиться в «Доверенных корневых центрах сертификации» (Trusted Root Certification Authorities) в хранилище ОС или браузера.

Проблемы, ломающие доверие:

• Отсутствует промежуточный сертификат — разработчик не включил его в подпись (поле «Цепочка сертификатов» неполная). Windows не может построить путь к корню. Решение: переподписать файл с включением полной цепочки (signtool sign /ac intermediate.crt …).
• Корневой УЦ не в хранилище — редко для крупных публичных УЦ (DigiCert, GlobalSign, Sectigo, Entrust), бывает при частных PKI или малоизвестных УЦ. Требует ручной установки корня.
• Отозванный сертификат (CRL/OCSP) — компрометация ключа, прекращение деятельности, ошибка выдачи. Проверяется автоматически ОС при наличии интернета; можно проверить вручную: вкладка «Состав» → «Сведения» → «Точки распространения CRL» / «Доступ к информации об авторизации».
• Слабый алгоритм подписи — SHA-1, MD5. Современные ОС блокируют такие подписи. Нужен SHA-256 или выше.

Типичные признаки подделки или подозрительного сертификата

• Subject.O = «Individual», «Self-Signed», «Test», «Developer» — самоподписанный или тестовый сертификат. Не подходит для распространения ПО.
• Subject.O содержит известное название (Microsoft, Google, Adobe), но Issuer — неизвестный УЦ или самоподписанный — явная подделка. Легальные сертификаты крупных вендоров выдаются только топовыми УЦ.
• Несовпадение домена в SAN и официального сайта — сертификат выдан на example-software.com, а официальный сайт — example.com. Возможно, сертификат получен мошенниками на похожий домен.
• EV-сертификат без serialNumber / jurisdiction полей — нарушение профиля EV (CA/Browser Forum Baseline Requirements). Такой сертификат не должен быть выпущен.
• Срок действия истёк, нет timestamp — подпись недействительна. Файл мог быть подписан давно, сертификат просрочен, timestamp не проставлен.
• Ключ подписи не для Code Signing — расширение Key Usage / Extended Key Usage должно содержать Code Signing (1.3.6.1.5.5.7.3.3). Если только Server Auth или Client Auth — сертификат не для подписи кода.

Пошаговая проверка подписи файла в Windows

1. Правый клик на файл → «Свойства» → вкладка «Цифровые подписи».
2. Если список пуст — файл не подписан. Прекратите установку, если ожидаете подписанный файл.
3. Выберите подпись (обычно одна) → кнопка «Сведения».
4. В открывшемся окне: «Сведения о подписи» → должен быть текст «Цифровая подпись в порядке» / «The digital signature is OK». Если есть предупреждение — читайте его внимательно.
5. Кнопка «Просмотреть сертификат» → вкладка «Состав» → «Сведения». Проверяйте поля из списка выше.
6. Вкладка «Путь сертификации» (Certification Path) — должна быть цепочка: Корневой УЦ → Промежуточный УЦ → Сертификат издателя. Все элементы со значком «ОК» (зелёная галочка).
7. При необходимости: «Сведения» → «Точки распространения CRL» / «Доступ к информации об авторизации» → проверьте отзыв в браузере (вставьте URL в адресную строку).

Для автоматизированной проверки в скриптах/пайплайнах используйте signtool verify /pa /v file.exe (Windows SDK) или Get-AuthenticodeSignature в PowerShell. Они возвращают статус цепочи, timestamp, отзыв и Subject.

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

Subject.O совпадает с ожидаемым

Цепочка валидна, timestamp есть

Сертификат не отозван

serialNumber (ИНН/рег. номер)

SAN URI — официальный сайт

Корневой сертификат УЦ в хранилище «Доверенные корневые» на вашем ПК

Скачан ли файл с официального HTTPS-сайта

Совпадает ли SHA-256 хеш с опубликованным

Timestamp валиден, TSA доверен

Дата подписания (если известна) внутри срока действия сертификата

Ситуация	Что проверить	Решение
Файл подписан OV-сертификатом, SmartScreen ругается «Неизвестный издатель»	Это нормально для нового сертификата. Репутация накапливается за дни/недели распространения. Можно запустить, если доверяете источнику загрузки (официальный сайт, проверенный хеш).
Файл подписан EV-сертификатом, но Subject.O — незнакомая организация	Проверьте ИНН в ФНС, зайдите на сайт из SAN. Если всё сходится — это легальная компания, возможно, подрядчик или дочерняя структура вендора.
Подпись валидна, но Issuer — частный УЦ (Corporate CA)	Типично для внутренних инструментов компании. Если файл пришёл извне — не запускайте, если не уверены в легитимности этого УЦ.
Файл без подписи, но с заявлением «подписан» на сайте	Сравните хеш (certutil -hashfile file.exe SHA256). Если совпадает — файл не модифицирован при загрузке. Подпись не обязательна для целостности, но желательна для идентификации автора.
Сертификат истёк, timestamp есть	Подпись считается действительной. Файл можно запускать.
Сертификат истёк, timestamp отсутствует	Подпись недействительна. Не запускайте без повторной подписи актуальным сертификатом.

Ограничения проверки сертификата

Даже идеально валидный EV-сертификат с правильными полями не гарантирует:

• Отсутствие вредоносного кода — сертификат подтверждает кто подписал, а не что внутри. Легальная компания может быть скомпрометирована (Supply Chain Attack), ключ украден, или сборка подменена на CI/CD.
• Актуальность бинарника — старый файл с уязвимостью может иметь валидную подпись. Проверяйте версии и даты сборки.
• Идентичность разработчика-физического-лица — сертификат выдаётся на юрлицо. Кто именно нажал кнопку «подписать» — вопрос внутренних процессов компании (разделение ролей, MFA на токене, аудит логов HSM).

Поэтому проверка сертификата — необходимый, но не достаточный этап. Дополняйте её: проверкой хешей (SHA-256) из официальных источников, сканированием антивирусом/EDR, запуском в песочнице для подозрительных файлов, контролем версий и источниками распространения.

Что делать, если обнаружили подозрительный сертификат

1. Не запускайте файл.
2. Сохраните копию файла для анализа (в архиве с паролем, чтобы не сработал антивирус).
3. Сообщите в службу безопасности вашей организации (если на рабочем ПК) или в поддержку вендора, чьё имя используется в сертификате.
4. УЦ, выдавший сертификат, можно найти по полю Issuer. На сайте УЦ обычно есть форма abuse/revocation request — отправьте туда файл и скриншоты сертификата. УЦ обязан расследовать и отозвать сертификат при подтверждении мошенничества.
5. Если файл скачан с официального сайта по HTTPS — вероятность подделки минимальна, но возможен взлом сайта или CDN. Сравните хеш.

Чек-лист быстрой проверки перед запуском

• Вкладка «Цифровые подписи» не пуста.
• Статус подписи: «Цифровая подпись в порядке».
• Subject.O — известная вам организация (или проверяемая через реестр/сайт).
• Subject.CN — осмысленное название продукта/компании, не «Test»/«Developer».
• EV: есть serialNumber (ИНН/рег.номер) и jurisdiction — проверьте в открытом реестре.
• SAN URI — официальный домен организации.
• Issuer — известный публичный УЦ (DigiCert, GlobalSign, Sectigo, Entrust, Actalis, SSL.com и др.).
• Вкладка «Путь сертификации» — полная цепочка до доверенного корня, все зелёные галочки.
• Timestamp присутствует (подпись жива после истечения сертификата).
• Key Usage / EKU содержит Code Signing (1.3.6.1.5.5.7.3.3).
• Алгоритм подписи — SHA-256 или выше.

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

Сертификат подтверждает личность издателя через проверенные УЦ поля Subject (O, CN, serialNumber, jurisdiction) и SAN (URI). Уровень валидации (EV/OV) определяет глубину этой проверки и требования к защите ключа. EV даёт мгновенную репутацию и строгие поля; OV — проверенное лицо, но репутация накапливается. Всегда проверяйте полную цепочку доверия, наличие timestamp и соответствие домена в SAN официальному сайту. Сертификат — это доказательство авторства, а не гарантия безопасности кода. Сочетайте проверку подписи с верификацией хешей, репутацией источника загрузки и сканированием защитными средствами.

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