Доверие к российским УЦ, CRL и OCSP в GPGSM¶
Что происходит при проверке ГОСТ-подписи¶
Математическая правильность подписанных данных, доверие к сертификату, статус отзыва, назначение ключа и срок действия — разные проверки. GOODSIG / VALIDSIG подтверждают математическую сторону, но не означают, что подписант обязательно является доверенным лицом по правилам организации. TRUST_FULLY в рабочем режиме полезен только при правильно настроенном и проверенном доверенном корне и реально выполненных проверках отзыва.
В НАЙС.ОС gpgsm использует dirmngr для CRL/OCSP и собственный trustlist.txt; импорт открытого сертификата не добавляет доверенный корень автоматически. GnuPG NiceSOFT r12 содержит изменения криптографической проверки ГОСТ-подписей для цепочек сертификатов, CRL и OCSP. Поддержка конкретной схемы построения цепочки для каждого российского УЦ должна испытываться отдельно.
Зафиксированные результаты реального испытания¶
На niceos-gost один запуск GPGSM завершился с invalid certification chain: Синтаксическая ошибка в URI, хотя сама подпись показывала GOODSIG / VALIDSIG. После дальнейшей настройки и использования CRL-кэша обычный запуск с включёнными проверками завершился:
В диагностическом режиме no_crl и no_policy также был код 0, но они не являются заменой полноценной штатной проверки.
Один реальный CRL ФНС скачан; метки времени: lastUpdate=Oct 24 02:50:01 2026 GMT, nextUpdate=Oct 31 15:10:00 2026 GMT. Использование локальных файлов ~/.gnupg/crls.d/crl-*.db в Dirmngr подтверждено. Первоначальная ошибка URI остаётся неразобранной: при новых CRL или пустом кэше может повториться.
Как проверять систему¶
gpgconf --list-components | grep -E 'gpgsm|dirmngr'
gpgsm --list-keys
ls -ld ~/.gnupg
ls -l ~/.gnupg/trustlist.txt ~/.gnupg/policies.txt 2>/dev/null || true
Для последующей проверки подписанного файла:
При аудите корневых сертификатов удостоверяйтесь, что отпечаток получен по проверенному независимому каналу; не объявляйте произвольный полученный файл доверенным только потому, что GPGSM удалось его импортировать.
Как безопасно диагностировать CRL¶
openssl x509 -inform DER -in signer.cer -noout -ext crlDistributionPoints
openssl x509 -inform DER -in signer.cer -noout -ext authorityInfoAccess
В некоторых сертификатах реальные URL соседствуют с внутренними короткими именами серверов УЦ. Невозможность разрешить внутреннее имя не доказывает синтаксическую ошибку какого-либо конкретного URI: нужно смотреть трассировку dirmngr и реальный ответ сервера.
Журнал Dirmngr может содержать служебные адреса, идентификаторы сертификатов и персональные данные. Не публикуйте его целиком. Включайте verbose/debug-level временно, с отдельной защищённой директорией для логов, и возвращайте настройки после диагностики.
Разделение лабораторного и рабочего режима¶
Флаги --disable-crl-checks, --disable-policy-checks, --always-trust применимы только для отдельных диагностических задач. В повседневной проверке реального подписанного документа недопустимо незаметно отключать проверку отзыва, политики или цепочки. Для самоподписанных лабораторных адресатов при тестовом --encrypt допускается явно указанное --always-trust: это исключение на время лабораторного опыта, а не административная настройка по умолчанию.
Если подтверждена математическая подпись, но не установлено доверие, вывод для пользователя должен быть: «Подпись математически корректна; доверие/статус сертификата не подтверждены», а не просто «Подпись действительна».
См. диагностику и доказательства.