Проверка CMS: отделяем криптографию от доверия¶

Разбор detached-подписи, вложенного содержимого и типичных ошибок проверки в OpenSSL.

Документация ПО — НАЙС.ОС CLOUD. Это самостоятельная учебно-справочная статья. Команды приведены для изучения и диагностики; операции с ключами, дисками и действующими сервисами выполняют только после резервного копирования и проверки назначения.

Перед началом¶

Для проверки нужны точные исходные байты подписанного документа, CMS-подпись и доверенный источник сертификатов. На реальном стенде часть ГОСТ-операций выполняется только при наличии соответствующего Provider/Engine. Поэтому первая цель — корректно разобрать формат и убедиться, какие алгоритмы требуется реализовать.

Случай 1. Вложенный SignedData¶

openssl cms -cmsout -print -inform DER -in signed.der | head -120
openssl cms -verify -binary -inform DER   -in signed.der   -CAfile trusted-ca.pem   -out /tmp/cms-verified-content.bin

Файл trusted-ca.pem должен содержать реальные доверенные сертификаты для данной процедуры. Отсутствие доверенных сертификатов — не повод глобально выключать проверку.

Случай 2. Отсоединённая подпись¶

openssl cms -verify -binary -inform DER   -in detached.der   -content original.bin   -CAfile trusted-ca.pem   -out /tmp/cms-verified-content.bin

Опция -binary нужна, когда важны точные байты. Иначе различия канонизации могут неожиданно изменить объект проверки. Важнейшая диагностика — сохранить контрольную сумму original.bin и проверить, что из системы документооборота извлекается именно тот файл, который был подписан.

Случай 3. Просто посмотреть структуру¶

openssl cms -cmsout -print -inform DER -in detached.der | less
openssl asn1parse -inform DER -in detached.der -i | head -100

Эти команды не удостоверяют подлинность подписи и не проверяют статус сертификата. Они позволяют увидеть используемые OID и структуру. Если формат PEM, измените -inform на PEM; не конвертируйте бинарный файл в текст принудительно.

Почему `-noverify` нельзя считать успехом¶

Отключение проверки сертификата решает только одну диагностическую задачу: отделить проблему доверия от математического расчёта. Производственный результат обязан учитывать цепочку доверия, назначение ключа, сроки, отзыв, политику и ограничения приложения. Поэтому «CMS signature verified» при ослабленных флагах нельзя представлять как юридически и эксплуатационно полноценную проверку.

Типовые неисправности¶

Симптом	Следующее действие
`unsupported` / `unknown algorithm`	Найти числовой OID и проверить фактически загруженный ГОСТ-провайдер
`content verify error`	Сверить исходный файл и режим detached/attached
`certificate verify error`	Проверить доверенные корни, промежуточные УЦ, сроки и назначения
Некорректный ASN.1	Зафиксировать байты, проверить PEM/DER и внешний `ContentInfo`
Грамотная проверка локально, отказ у контрагента	Сравнить параметрический набор, цепочку, байты подписи и алгоритмические параметры

Как оформлять протокол¶

Сохраняйте версии OpenSSL и Provider, SHA-256 публичных файлов, применённые команды, OID, цепочку, результат и расшифровку отказа. Не прикладывайте в документацию реальные ключи, пароли и содержимое закрытых корпоративных документов.

Первоисточники и дополнительное чтение¶

RFC 5652 — базовая структура CMS и типы содержимого.
Р 1323565.1.025-2019 — российские рекомендации по CMS.
RFC 9215 — ГОСТ-2012 в сертификатах и списках отзыва.
RFC 7836 — HMAC, PRF, KDF, VKO и параметры кривых.