Кратко

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

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

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

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

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

Что действительно доказывает метка

RFC 3161 строится вокруг MessageImprint: идентификатора алгоритма хеширования и значения хеша данных. Центр проверяет алгоритм и длину, но не исследует саму программу. Токен содержит политику, уникальный серийный номер и genTime и подписывается отдельным ключом временных меток.

Токен не утверждает, что программа безопасна. Он доказывает, что конкретный хеш был предъявлен в рамках указанной политики. Он не подтверждает контроль издателя над всеми путями подписи и не доказывает исчезновение старой версии со всех зеркал.

Проверка остаётся активной работой. RFC требует проверить ответ, сертификат центра, хеш, алгоритм, подпись и своевременность. Microsoft отражает это разделение в SignTool: sign, timestamp и verify — разные команды. В режиме RFC 3161 параметр /tr задаёт сервер, а /td — алгоритм хеша метки. Проверка может учитывать цепочку сертификатов и статус отзыва, а не только наличие подписанной структуры.

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

Отзыв создаёт границу во времени

Требования CA/Browser Forum охватывают публично доверенные сертификаты подписи кода и связанные центры временных меток. Выдающие их центры сертификации должны эксплуатировать службу RFC 3161, рекомендовать её использование и отклонять MessageImprint на SHA-1.

Требования объясняют, почему отзыв — не простое удаление. Один сертификат мог подписать один объект или тысячи; его отзыв способен сделать недействительными как подозрительные, так и исправные программы. Центр должен начать расследование обоснованного сообщения о проблеме в течение двадцати четырёх часов. При компрометации ключа действующей датой должен стать самый ранний подтверждённый момент подозрения.

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

У центра временных меток есть собственная граница отказа. RFC 3161 различает штатное прекращение работы и компрометацию ключа. При прекращении без компрометации и корректной причине старые токены могут оставаться действующими. При компрометации ключа его токенам нельзя доверять автоматически; важными становятся журналы аудита или вторая независимая метка.

Знаменатель — все распространённые артефакты

Реестра сертификатов недостаточно. Издателю нужно знать, какой артефакт подписан, какой токен к нему приложен, где он остаётся доступным и как его оценивают целевые проверяющие системы.

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

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

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

Границы доказательств

RFC 3161 определяет токен и проверку, но не сертифицирует конкретного поставщика. Требования CA/Browser Forum не унифицируют все ОС. Документация Microsoft устанавливает заявленное поведение SignTool, Authenticode и ClickOnce, а не всей программной среды.

Здесь никому не приписывается компрометация. Истечение, ротация, отзыв и сбой центра времени — разные события. Защищаемый переход сохраняет это различие в доказательствах и решении.

Источники