Новый и отозванный сертификат одного разработчика: как сравнить и что проверить

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

Почему вообще возникает пара «отозванный + новый»

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

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

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

Что означают отзыв и перевыпуск на практике

Отзыв фиксируется в двух механизмах проверки статуса:

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

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

Ещё один важный нюанс — метка времени. Если программа была подписана с меткой времени, то подпись остаётся действительной даже после отзыва сертификата: система проверяет, что файл был подписан до момента отзыва. Без метки времени отзыв сертификата делает недействительными все подписи, выполненные им, включая уже распространённые копии программ. Именно поэтому добросовестные разработчики всегда используют метку времени, а её отсутствие — повод насторожиться.

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

Откройте свойства обоих сертификатов (в Windows — двойной щелчок по файлу сертификата или вкладка «Состав» в свойствах цифровой подписи файла; в macOS — приложение «Связка ключей»). Сравните следующие поля:

Поле сертификата	Должно совпадать?	О чём говорит расхождение
Субъект (Subject): название организации, страна	Да, как правило	Другое имя — возможно, это уже другая компания или подделка имени
Издатель (Issuer)	Обычно да	Смена удостоверяющего центра допустима, но требует дополнительной проверки новой цепочки
Отпечаток (Thumbprint, SHA-1/SHA-256)	Нет, всегда разный	Совпадение отпечатков означало бы, что это один и тот же сертификат
Серийный номер	Нет, всегда разный	Совпадение невозможно для легально перевыпущенного сертификата
Срок действия (Valid from / Valid to)	Нет	Новый сертификат начинается после даты выпуска; даты помогают установить хронологию
Назначение ключа (Enhanced Key Usage)	Да, если назначение то же	Например, «Подписывание кода» должно присутствовать, если сертификат используется для ПО
Статус отзыва (CRL/OCSP)	Старый — «отозван», новый — «действителен»	Если новый тоже числится отозванным, доверять ему нельзя

Ключевая логика такая: идентичность разработчика подтверждают субъект и цепочка доверия, а уникальность каждого экземпляра — отпечаток и серийный номер. Совпадение имени при разных отпечатках — нормальная картина перевыпуска. Несовпадение имени — сигнал, что перед вами, скорее всего, разные владельцы.

Пошаговый порядок сравнения

1. Сохраните или найдите оба сертификата: старый можно извлечь из ранее скачанной версии программы, новый — из свежего дистрибутива или письма удостоверяющего центра.
2. Откройте свойства каждого и зафиксируйте субъект, издателя, отпечаток SHA-256, серийный номер и срок действия.
3. Убедитесь, что имя субъекта и организация совпадают (допустимы косметические различия вроде добавления отдела OU).
4. Проверьте статус каждого сертификата через CRL или OCSP: ссылки на точки распространения CRL указаны в самом сертификате в поле «Точки распространения списка отзыва».
5. Постройте цепочку доверия каждого сертификата до корневого центра и убедитесь, что цепочка не содержит ошибок и предупреждений.
6. Для подписанных файлов проверьте, что подпись целая (файл не изменялся после подписания) и, если есть метка времени, что она попадает в период действия соответствующего сертификата.

Как проверить статус отзыва вручную

В Windows самый быстрый способ — утилита certutil, входящая в состав системы:

• certutil -verify -urlfetch cert.cer — проверит сертификат из файла, включая загрузку списков отзыва по ссылкам;
• certutil -URL cert.cer — откроет диалог проверки URL-адресов AIA/CDP, где видно, доступны ли OCSP-сервер и CRL.

В отчёте ищите строки о статусе: «сертификат отозван» или «revoked» для старого и «проверка отзыва пройдена» для нового. Аналогичные проверки доступны в OpenSSL (openssl verify -crl_check) и в графических просмотрщиках сертификатов.

Если точка распространения CRL недоступна (например, удостоверяющий центр прекратил работу), система может показать статус «неизвестно». Это не равно «действителен»: отсутствие данных об отзыве — само по себе ограничение доверия, о котором стоит помнить, особенно для критически важного ПО.

Что происходит с уже установленным и подписанным ПО

Здесь многое зависит от метки времени:

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

На практике это проявляется так: после громкого отзыва сертификата крупного разработчика пользователи временно видят предупреждения SmartScreen или UAC для его программ, пока разработчик не перевыпустит подписанные сборки новым сертификатом. Это ожидаемое следствие, а не признак заражения.

Признаки, которые должны насторожить

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

• Имя субъекта нового сертификата отличается хотя бы на один символ, использует другую организационно-правовую форму или другую страну;
• Новый сертификат выпущен удостоверяющим центром, которого нет в доверенных корневых хранилищах вашей системы, и требует ручной установки корневого сертификата;
• Разработчик предлагает вам вручную установить промежуточный или корневой сертификат, чтобы «убрать предупреждения»;
• Оба сертификата — и старый, и новый — числятся отозванными;
• Дата начала действия нового сертификата раньше даты отзыва старого без объяснимых причин;
• Файл подписан новым сертификатом, но цифровая подпись повреждена или отсутствует вовсе.

Любой из этих признаков — основание приостановить установку и уточнить информацию у разработчика по официальным каналам, а не по контактам из самого дистрибутива.

Типичные ошибки при сравнении

Ошибка 1: сравнение только по названию организации. Имя легко имитировать визуально, особенно с похожими символами. Сопоставляйте полное содержимое Subject и цепочку до корня, а не короткое отображаемое имя.

Ошибка 2: вывод «новый сертификат = надёжный». Сам факт недавнего выпуска ничего не гарантирует. Доверие определяется цепочкой до доверенного корня и актуальным статусом, а не датой.

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

Ошибка 4: доверие к скриншотам. Скриншот свойств сертификата легко подделать. Сравнивайте сертификаты, извлечённые непосредственно из файлов, которые вы собираетесь запускать.

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

Сценарии: что делать в зависимости от ситуации

• Имя совпадает, старый отозван, новый действителен, цепочка одна. Штатный перевыпуск. Можно работать с ПО, подписанным новым сертификатом; старые сборки с меткой времени остаются действительными.
• Имя совпадает, но издатель другой. Возможна смена удостоверяющего центра. Проверьте, что новый корень есть в доверенном хранилище системы, и при сомнениях уточните у разработчика причину смены.
• Имя отличается незначительно. Вероятна имитация. Не устанавливайте ПО, сверьтесь с официальным сайтом разработчика по независимому каналу.
• Новый сертификат также отозван. Критический сигнал: либо повторная компрометация, либо мошенничество. Установку отложите до официальных разъяснений.
• Статус проверить не удаётся (CRL/OCSP недоступны). Решение принимайте по совокупности: репутация источника загрузки, наличие метки времени, целостность подписи. Для ответственного ПО лучше дождаться восстановления доступности проверки.

Практические рекомендации

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

Перед тем как принять решение, сделайте следующее:

1. Извлеките оба сертификата из реальных файлов и сохраните их отпечатки SHA-256 для сравнения.
2. Выполните проверку отзыва для каждого сертификата отдельно.
3. Убедитесь, что цепочка нового сертификата заканчивается в доверенном корневом хранилище вашей системы.
4. Сверьте название организации с информацией на официальном ресурсе разработчика, открытом независимо от дистрибутива.
5. Загружайте ПО только из первоисточника или проверенных зеркал: сравнение сертификатов не заменяет контроль источника загрузки.

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

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