Подлинность документа или сообщения подтверждают проверкой электронной цифровой подписи: валидатор пересчитывает хэш, сопоставляет его с подписью и проверяет сертификат подписанта. Надёжный результат означает, что данные не изменялись после подписания, сертификат действителен, а его цепочка доверия признана системой или организацией.
Что важно учесть перед проверкой подписи
- Проверяйте именно исходный файл или сообщение: даже небольшое изменение содержимого обычно делает подпись недействительной.
- Разделяйте целостность данных и личность подписанта: корректная криптографическая подпись сама по себе не доказывает, что сертификат выдан нужному человеку.
- Учитывайте срок действия сертификата, его отзыв и назначение ключа.
- Не загружайте конфиденциальные документы в неизвестные сервисы электронной подписи документов.
- Сохраняйте отчёт проверки, сертификат и исходный файл, если результат нужен для спора, аудита или комплаенса.
Принципы работы цифровой подписи и цели подтверждения подлинности
Цифровая подпись создаётся закрытым ключом подписанта. Программа формирует хэш данных, подписывает его закрытым ключом, а получатель использует открытый ключ из сертификата, чтобы проверить соответствие.
Проверка электронной подписи обычно отвечает на три разных вопроса:
- Изменялось ли содержимое после подписания?
- Связана ли подпись с указанным сертификатом?
- Можно ли доверять сертификату и его владельцу в конкретном контексте?
Метод подходит для договоров, служебных файлов, электронных писем, API-сообщений и архивов. Не стоит считать подпись достаточным доказательством, если сертификат неизвестен, документ получен из сомнительного источника или отсутствуют правила признания подписи в вашей организации.
Криптография и стандарты: RSA, ECDSA, GOST - что выбрать в 2026
RSA и ECDSA встречаются в международных форматах и инфраструктуре открытых ключей. ГОСТ применяется в российских информационных системах, где это предусмотрено требованиями организации или регуляторного контура. Выбор определяется не только алгоритмом, но и форматом контейнера, программным обеспечением и политикой доверия.
Для проверки обычно понадобятся:
- исходный документ или точное сообщение;
- файл подписи либо контейнер с подписью;
- сертификат подписанта и, при необходимости, сертификаты удостоверяющих центров;
- программа или сервис, поддерживающий используемый формат;
- доступ к спискам отозванных сертификатов или OCSP, если проверка должна учитывать статус сертификата.
Например, OpenSSL позволяет проверить подпись отдельного файла, если известны формат подписи и хэш-алгоритм:
openssl dgst -sha256 -verify public_key.pem -signature signature.bin document.pdfУспешный вывод означает только криптографическое соответствие открытого ключа, подписи и файла. Доверие к владельцу сертификата и статус сертификата нужно проверять отдельно.
Шаг за шагом: как валидировать подпись на практике
Перед началом оцените риски и ограничения:
- Не открывайте подозрительные вложения на рабочем компьютере без проверки антивирусом и источника.
- Не устанавливайте криптографические плагины из рекламы, писем или непроверенных каталогов.
- Не вводите PIN-код, пароль закрытого ключа или данные токена на стороннем сайте.
- Для персональных и коммерческих документов выбирайте локальную проверку либо сервис, одобренный вашей организацией.
- Зафиксируйте исходные данные.
Сохраните документ, сообщение, файл подписи и сопроводительные метаданные без переименования и редактирования. Для контроля можно рассчитать хэш:
sha256sum document.pdf - Определите формат подписи.
Проверьте расширение и структуру контейнера: подпись может быть отдельным файлом, встроенной в PDF или помещённой в контейнер CMS/CAdES, XML или другой формат.
- Выберите доверенный валидатор.
Используйте корпоративное ПО, официальное приложение удостоверяющего центра или локальные криптографические инструменты. Для чувствительных данных не передавайте файл в публичный сервис.
- Проверьте криптографическое соответствие.
Валидатор должен подтвердить, что подпись относится к конкретному содержимому. Если документ изменён, результат обычно отображается как недействительный или повреждённый.
- Проверьте сертификат подписанта.
- срок действия;
- назначение ключа;
- имя владельца и реквизиты организации;
- издателя сертификата;
- наличие отзыва.
- Проверьте цепочку доверия.
Убедитесь, что сертификат подписанта связан с доверенным корневым центром, а промежуточные сертификаты доступны и не просрочены.
- Сопоставьте результат с контекстом.
Сравните владельца сертификата с ожидаемым отправителем через независимый канал. Для договора дополнительно проверьте полномочия подписанта и правила документооборота.
- Сохраните доказательства проверки.
Экспортируйте отчёт, зафиксируйте дату проверки, версию программы и полученный статус. Не заменяйте исходный файл отредактированной копией.
Инструменты и сервисы для проверки: сравнение и таблица возможностей
| Подход | Подходящие задачи | Преимущества | Ограничения и риск |
|---|---|---|---|
| Локальное криптографическое ПО | Конфиденциальные документы, корпоративный документооборот | Данные не покидают компьютер; можно настроить доверенные центры | Требует установки, настройки и актуальных сертификатов |
| Официальный валидатор удостоверяющего центра | Проверка сертификатов и поддерживаемых форматов | Понятный отчёт и профильная поддержка | Возможны ограничения по форматам и передаче файлов |
| Онлайн-сервис проверки | Неконфиденциальные документы и разовая проверка | Не требуется локальная настройка | Риск разглашения данных; доверие зависит от оператора |
| OpenSSL или аналогичный CLI-инструмент | Автоматизация, тестирование, API-интеграции | Воспроизводимость и скриптование | Нужно самостоятельно проверять сертификаты, форматы и параметры |
После проверки используйте чек-лист:
- файл соответствует исходному содержимому;
- подпись относится к правильному файлу или сообщению;
- сертификат не просрочен;
- сертификат не отозван либо причина отсутствия проверки статуса зафиксирована;
- цепочка доверия построена до доверенного корня;
- назначение сертификата допускает подписание;
- владелец сертификата совпадает с ожидаемым подписантом;
- результат сохранён в отчёте с датой и версией инструмента.
Пример структурированного результата, который удобно сохранять в журнале:
{
"signatureValid": true,
"certificateStatus": "valid",
"trustChain": "trusted",
"documentHash": "sha256:...",
"checkedAt": "2026-09-04"
}Аудит цепочки доверия: сертификаты, CRL и OCSP в деталях
Криптографическая проверка и проверка статуса сертификата - разные операции. CRL содержит список отозванных сертификатов, а OCSP позволяет запросить статус конкретного сертификата у сервера центра сертификации.
При аудите ищите такие ошибки:
- корневой сертификат добавлен в доверенные без проверки происхождения;
- сертификат подписанта просрочен на момент подписания или проверки;
- не удалось получить CRL или ответ OCSP, но программа трактует это как полное доверие;
- сертификат предназначен для аутентификации, а не для подписи;
- не хватает промежуточного сертификата;
- алгоритм или размер ключа не соответствует политике безопасности;
- время подписи взято только с локального компьютера и не подтверждено меткой времени;
- проверяется не тот файл, который был подписан;
- онлайн-сервис не объясняет, какие центры сертификации считает доверенными.
Для снижения риска задайте явный список доверенных корней, обновляйте средства проверки, фиксируйте сетевые ошибки и требуйте усиленную проверку времени для документов, значимых в долгосрочном архиве.
Типовые сценарии проверки: документы, электронная почта и API-интеграции
- Документы. Используйте валидатор формата документа, затем отдельно проверьте сертификат и полномочия подписанта. При обмене с контрагентом согласуйте формат подписи заранее.
- Электронная почта. Проверяйте подпись письма вместе с заголовками и сертификатом отправителя. Адрес в поле отправителя не заменяет проверку сертификата.
- API-интеграции. Верифицируйте подпись на исходных байтах тела запроса до преобразования JSON парсером. Контролируйте повторную отправку сообщений через идентификатор запроса, время действия и журнал событий.
- Внутренний архив. Сохраняйте исходный объект, подпись, сертификат, цепочку доверия и отчёт проверки. Периодически проверяйте доступность архивных сертификатов и меток времени.
Типичные проблемы при верификации и способы их устранения
Почему подпись стала недействительной после сохранения документа?
Редактор мог изменить структуру файла, метаданные или кодировку. Возьмите оригинал из источника и не пересохраняйте его перед проверкой.
Что означает сообщение о неизвестном издателе сертификата?
В системе нет доверенного корневого или промежуточного сертификата. Получите цепочку из официального источника и проверьте её перед добавлением в доверенные.
Можно ли считать сертификат действительным, если CRL или OCSP недоступны?
Нельзя безоговорочно считать статус подтверждённым. Зафиксируйте невозможность онлайн-проверки и используйте допустимые организацией архивные данные или другой доверенный канал.
Почему подпись проверяется, но имя подписанта вызывает сомнения?
Криптография подтверждает связь подписи с сертификатом, а не реальную роль человека в сделке. Сверьте реквизиты сертификата и полномочия подписанта независимо.
Безопасно ли использовать сервисы электронной подписи документов онлайн?
Только если оператор доверен, условия обработки данных приемлемы, а документ не содержит запрещённую к передаче информацию. Для конфиденциальных файлов предпочтительнее локальная проверка.
Что делать, если формат подписи не поддерживается?
Определите контейнер и алгоритм, установите совместимое официальное ПО или запросите у отправителя другой согласованный формат. Не преобразуйте документ наугад: конвертация может нарушить подпись.
Как подписать документ электронной подписью после проверки?
Выберите официальный инструмент, подключите сертификат и носитель ключа, укажите исходный файл и подтвердите операцию средствами защиты ключа. Перед отправкой проверьте созданный контейнер и сохраните подписанную копию отдельно.
Об авторе
Павел Морозов - автор материалов о проверке целостности данных, криптографических инструментах и цифровой безопасности.