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

PKI-лаборатория: X.509, цепочка, профили ключа и ошибки

Чтение сертификата ГОСТ-2012 и различение подписи сертификата, ключа субъекта и правил доверия.

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

Содержимое сертификата

У X.509 есть собственная подпись издателя, алгоритм открытого ключа субъекта, расширения и сведения о сроке действия. Неверно говорить «сертификат ГОСТ» без уточнения этих полей: сертификат может быть подписан одним алгоритмом, а содержать открытый ключ другой системы.

Важные поля

  • Signature Algorithm: алгоритм, которым УЦ подписал сертификат.
  • Subject Public Key Info: тип и параметры ключа субъекта.
  • Basic Constraints: принадлежит ли сертификат удостоверяющему центру.
  • Key Usage: разрешённые операции с ключом.
  • Extended Key Usage: прикладные назначения, например аутентификация сервера.
  • Subject Alternative Name: имена, по которым проверяется сервер.
  • Authority Key Identifier и Subject Key Identifier: связывание сертификатов в цепочку.
  • CRL Distribution Points и Authority Information Access: источники статусов и промежуточных сертификатов.

Получаем читаемое представление

openssl x509 -in cert.pem -noout -text
openssl x509 -in cert.pem -noout -subject -issuer -serial -dates
openssl x509 -in cert.pem -pubkey -noout > /tmp/cert-public-key.pem

Экспорт открытого ключа допустим, но не является свидетельством, что реализация умеет создавать/проверять подпись этим ключом. Для неизвестного ГОСТ-OID при отсутствии криптопровайдера вывод может быть неполным.

Сверяем публичные ключи и параметры

Для ГОСТ Р 34.10-2012 в SubjectPublicKeyInfo ожидаются OID алгоритма и параметры открытого ключа. Их надо сверить с RFC 9215. При отсутствии необходимых параметров возможна ситуация, когда сертификат структурно читается, но алгоритм подписи не может быть использован.

Проверка доверия

openssl verify -CAfile trusted-root.pem -untrusted intermediates.pem cert.pem

Это проверка сертификатной цепочки по правилам OpenSSL с заданными доверенными сертификатами, но она не доказывает успешной проверки отзыва и всех специфических требований к ГОСТ. Политику применения, проверку URL OCSP/CRL и проверку назначения ключа нужно оформить отдельно.

Пять контрольных вопросов

  1. Точно ли задан ожидаемый доверенный корень, а не любой сертификат с похожим именем?
  2. Присутствуют ли все промежуточные сертификаты?
  3. Относятся ли даты к доверенному источнику времени?
  4. Совпадают ли OID и назначение ключа с ожидаемым применением?
  5. Нужна ли проверка CRL или OCSP, и можно ли её провести в изолированном контуре?

Локальная инфраструктура НАЙС.ОС

Наличие файлов российских корневых сертификатов и установка пакета доверия не равны автоматическому включению всех этих сертификатов в хранилище доверенных якорей. Для подтверждения необходимо смотреть реальное состояние системного trust store (trust list), а затем проводить независимые проверки цепочки.

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

  • RFC 9215 — ГОСТ-2012 в сертификатах и списках отзыва.
  • Р 1323565.1.059-2024 — профиль OCSP с российскими алгоритмами.
  • RFC 7836 — HMAC, PRF, KDF, VKO и параметры кривых.