Почему сертификат файла может быть действительным только в прошлом

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

Как работает подпись файла и роль сертификата

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

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

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

Срок действия сертификата

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

При проверке подписи без дополнительных меток времени система использует текущие часы. Следовательно:

• Если подпись сделана, когда сертификат был ещё в пределах Not Before–Not After, а проверка выполняется позже, когда срок уже истёк, подпись будет отклонена.
• Наоборот, если проверка выполняется раньше, чем наступил Not Before, сертификат также считается недействительным, потому что centre ещё не гарантировал его подлинность.

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

Отзыв сертификата и его временная привязка

Помимо срока действия, сертификат может быть отозван центром до истечения Not After (например, из‑за компрометации закрытого ключа). Информация об отзыве публикуется в списках отзыва (CRL) или отвечает на запросы протокола OCSP. Эти данные также актуальны только на момент их публикации:

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

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

Почему без timestamp подпись считается действительной только для прошлого

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

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

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

Timestamping как способ зафиксировать момент подписи

Чтобы преодолеть зависимость от текущего времени, применяется доверенное timestamping (временное метки). При создании подписи к ней добавляется запрос к авторитетному сервису timestamps, который возвращает криптографически защищённую метку времени, подтверждающую, что существовал определенный набор данных (в данном случае подпись) в конкретный момент. Эта метка сама подписывается сертификатом центра timestamping, который обычно имеет длительный срок действия и строго контролируется.

При последующей проверке:

1. Извлекается timestamp и проверяется его собственная подпись (центр timestamping должен быть доверен и не отозван на момент проверки).
2. Из timestamp извлекается время T.
3. Срок действия и статус отзыва сертификата подписи оцениваются не по текущему времени, а по моменту T.

Если на момент T сертификат был ещё в пределах Not Before–Not After и не отозван, подпись считается валидной независимо от того, сколько времени прошло с тех пор. Это основа концепции long-term signature (долгосрочной подписи).

Ограничения и проверка timestamping

Сам timestamp зависит от доверия к центру timestamping. Поэтому необходимо убедиться, что:

• Центр timestamping включён в доверенную цепочку (его корневой сертификат присутствует в хранилище доверенных корней).
• Сертификат центра timestamping не истёк и не отозван на момент проверки timestamp.
• Сам timestamp не был подменён (его подпись проверяется стандартным способом).

Если центр timestamping compromised или его сертификат отозван, метка времени теряет свою силу, и проверка возвращается к оценке по текущему времени.

Практические шаги для обеспечения долгосрочной доверия к подписи файла

Если вам нужно, чтобы подпись оставалась проверяемой годами или десятилетиями, выполните следующее:

1. Выберите алгоритм хеширования и размер ключа, которые считаются криптостойкими на протяжении всего ожидаемого срока (например, SHA‑256 или выше, RSA 2048 bit или ECC P‑256).
2. Получите сертификат подписи от аккредитованного центра, у которого есть чётко опубликованные практики и поддержка timestamping.
3. При создании подписи обязательно включайте запрос к доверенному сервису timestamping (RFC 3161).
4. Сохраните вместе с файлом не только подпись, но и полученный timestamp‑token.
5. При проверке используйте программное обеспечение, которое умеет извлекать timestamp и проверять его цепочку доверия (например, OpenSSL, signtool, подписные модули в криптопровайдерах).
6. Регулярно обновляйте список доверенных корней и проверяйте, не отозван ли сертификат центра timestamping.
7. Если планируется архивирование на очень длительные сроки, рассмотрите возможность повторного timestamping (re‑timestamp) каждые несколько лет, чтобы переподписать метку новым доверенным центром, пока исходный ещё действителен.

Типичные ошибки и их последствия

• Проверка без учёта timestamp: приводит к ложному отклонению корректных старых подписей, когда срок сертификата уже истёк, но подпись была сделана до истечения.
• Использование самоподписанного центра timestamping без его включения в доверенные хранилища: делает метку бесполезной, так как проверка не сможет подтвердить её подлинность.
• Зависимость от одного центра timestamping без резерва: если этот центр позже будет компрометирован или его сертификат отозван, все ранее timestamped подписи могут стать непроверяемыми.
• Игнорирование алгоритмов хеширования: использование устаревших хешей (MD5, SHA‑1) делает подпись уязвимой к атакам коллизии, независимо от timestamp.

Когда достаточно проверки без timestamp

Для многих сценариев краткосрочного использования (например, распространение обновлений ПО, которые будут установлены в течение недели‑двух) требование долгосрочной подписи избыточно. В таких случаях достаточно:

• Убедиться, что сертификат подписи действителен на момент выпуска.
• Распространять обновления через надёжные каналы, чтобы уменьшить риск подмены.
• Отслеживать дату выпуска и рекомендовать пользователям обновляться до истечения срока сертификата.

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

Вывод

Сертификат файла считается действительным только в прошлом, потому что проверка по умолчанию привязывает срок действия и статус отзыва к моменту проверки, а не к моменту подписания. Без внешней фиксации времени (timestamp) мы не можем гарантировать, что сертификат был валиден именно тогда, когда создавалась подпись. Доверенное timestamping переносит точку оценки сертификата в момент, когда подпись действительно была выполнена, что позволяет сохранять доверие к файлу на arbitrarily long периоды, при условии, что сам центр timestamping остаётся доверен и не отозван.

Для практической работы:

• Если нужен краткосрочный срок – проверяйте сертификат по текущему времени, но следите за его датой окончания.
• Если требуется долгосрочная проверка – всегда включайте timestamp от надёжного центра и проверяйте его цепочку доверия.
• Регулярно обновляйте доверенные корни и отслеживайте отозванные центры timestamping, иначе метка времени потеряет свою силу.