Перейти к содержанию

Проверка доверия: УЦ, CRL, OCSP и GPGSM

На реальной НАЙС.ОС подпись КриптоПро сначала математически проверялась (GOODSIG, VALIDSIG), но цепочка не проходила проверку из-за ошибки «Синтаксическая ошибка в URI». Позднее обычный запуск — без отключения CRL и политик — завершился TRUST_FULLY, код 0. Причина первоначальной ошибки не локализована. Это важный эксплуатационный сценарий, требующий отдельного контроля.

Не смешивайте три независимых состояния

Проверка Вопрос Типичный признак
CMS-криптография Верно ли подписано содержимое? GOODSIG, VALIDSIG, отрицательный тест BADSIG
Доверенная цепочка Признаётся ли УЦ и назначение сертификата? TRUST_*, состояние trustlist
Проверка отзыва Не отозван ли сертификат по CRL/OCSP? Успешный ответ Dirmngr и проверка актуальных данных

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

Что увидели на стенде

  1. Импортирован конечный сертификат российского УЦ и обнаружены сертификаты цепочки.
  2. GPGSM проверил CMS математически, но Dirmngr в начале выдавал ошибку URI.
  3. Диагностический запуск с --disable-crl-checks --disable-policy-checks дал GOODSIG, VALIDSIG, TRUST_FULLY, код 0.
  4. Позже серия normal, no_crl, no_policy закончилась кодом 0 каждый, в том числе нормальный режим.
  5. CRL был скачан и прочитан через OpenSSL. Dirmngr в debug-журнале открывал существующие файлы кэша CRL.

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

Проверяем адреса CRL и OCSP сертификата

Команда работает с открытым сертификатом, не требует закрытого ключа:

openssl x509 -inform DER \
  -in /root/gost-cms-test/cryptopro-public.cer \
  -noout -ext crlDistributionPoints -ext authorityInfoAccess

В проверенном сертификате содержались общедоступные URL ФНС, а также внутреннее сетевое имя c0000-app005. Наличие внутреннего адреса само по себе не доказывает причину ошибки: Dirmngr может сначала успешно обратиться к другим источникам.

Проверяем общедоступный CRL

На момент испытания было получено около 41,85 МиБ DER CRL. При проверке OpenSSL поля дат содержали:

lastUpdate=Oct 24 02:50:01 2026 GMT
nextUpdate=Oct 31 15:10:00 2026 GMT

Для повторного испытания сохраните новую версию CRL, не ориентируйтесь на приведённые даты как на всегда актуальные:

curl -fL --max-time 60 \
  -o /root/gost-cms-test/fns.crl \
  'http://pki.tax.gov.ru/cdp/23f0da4a5de30c96e91f976a3e641689a1f8553c.crl'

openssl crl -inform DER \
  -in /root/gost-cms-test/fns.crl \
  -noout -issuer -lastupdate -nextupdate

Эта команда проверяет читаемость и даты, но сама по себе не подтверждает подлинность CRL или статус конкретного сертификата. Для настоящей проверки отзыва следует проверять подпись CRL доверенным издателем, область применения CRL и наличие серийного номера — либо использовать корректный OCSP-запрос.

Отладка Dirmngr без отключения защиты в производстве

Для временного получения диагностического журнала на тестовой системе:

umask 077
cat > /root/.gnupg/dirmngr.conf <<'CONF'
verbose
debug-level advanced
log-file /root/gost-cms-test/dirmngr-debug.log
CONF

gpgconf --kill dirmngr
gpgsm --verify /root/gost-cms-test/test.txt.sgn \
  /root/gost-cms-test/test.txt \
  > /root/gost-cms-test/verify-dirmngr.log 2>&1

После теста уберите диагностические опции, не удаляя другие пользовательские настройки. Если dirmngr.conf существовал до опыта, сначала сделайте резервную копию и восстановите её после завершения.

mv /root/.gnupg/dirmngr.conf \
  /root/.gnupg/dirmngr.conf.r20-debug-backup
gpgconf --kill dirmngr

Не переносите эти инструкции целиком в производственную систему с существующим dirmngr.conf: там файл следует изменить временно и аккуратно, сохраняя старые настройки.

Чего делать нельзя

  • Оставлять --disable-crl-checks и --disable-policy-checks постоянными параметрами проверки юридически значимых документов.
  • «Исправлять» недоверенный сертификат без независимой проверки подлинности корневого УЦ.
  • Считать, что успешный curl к .crl доказывает отсутствие отзыва.
  • Очищать все сертификаты и CRL в рабочем GnuPG ради лабораторной диагностики.
  • Публиковать полный DN реального подписанта в логах технического сайта.

Связанные статьи: диагностика, матрица, проверка подписи КриптоПро.