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

ГОСТ-сертификаты X.509 в НАЙС.ОС: что меняется для пользователя

Сертификат как удостоверение личности в цифровой системе

Сертификат X.509 связывает открытый ключ с владельцем — человеком, организацией или службой. В нём записаны имя, издатель, серийный номер, срок действия, назначения ключа, сведения об удостоверяющем центре (УЦ), идентификаторы алгоритмов и сама открытая часть ключа. Сертификат может применяться для электронной подписи документов, проверки подписи другого лица, защищённой почты и иных процессов, если они поддерживаются используемой прикладной системой.

Большая часть сертификата не зависит от того, использованы ли RSA, ECDSA или ГОСТ. Разница появляется в трёх полях: алгоритм и параметры открытого ключа, представление открытого ключа и алгоритм/формат подписи сертификата. Именно здесь важны расширения libksba НАЙС.ОС.

Какие поколения ГОСТ учитываются

Семейство Что распознаётся библиотекой Практическое значение
ГОСТ Р 34.10-2001 OID открытого ключа 1.2.643.2.2.19, параметры CryptoPro Работа с архивными сертификатами, ранними внедрениями и партнёрами со старыми ключами
ГОСТ Р 34.10-2012/256 OID 1.2.643.7.1.1.1.1 Распространённые современные ГОСТ-сертификаты
ГОСТ Р 34.10-2012/512 OID 1.2.643.7.1.1.1.2 Профили с 512-битным открытым ключом и соответствующей подписью
ГОСТ Р 34.11-94 Алгоритм хэширования старого семейства Проверка документов и сертификатов исторических профилей
ГОСТ Р 34.11-2012 «Стрибог» Подписи с хэшированием 256/512 бит Современные ГОСТ-подписи

Библиотека умеет распознавать ряд наборов параметров эллиптических кривых CryptoPro A/B/C, наборы обмена ключами Xch и кривые ТК26. Параметры тестовых кривых используются для испытаний; их появление в справочнике не означает рекомендацию применять их в производственной PKI.

Почему сертификат раньше мог не открываться

В X.509 открытый ГОСТ-ключ записан не точно так, как открытый ключ ECDSA. Координаты точки имеют предписанный порядок байтов и находятся внутри отдельной структуры. Если программа интерпретирует их неверно, она может не извлечь ключ либо сформировать неверные данные для криптографического механизма. У ГОСТ-подписей также особый двоичный формат. В НАЙС.ОС преобразование происходит внутри libksba, без ручной обработки пользователем.

Для администраторов это означает, что попытки «переделать сертификат в RSA» или изменить только расширение .cer на .crt не требуются. Сертификат остаётся ГОСТ-сертификатом; меняется способность системной библиотеки корректно его понимать.

Что такое OID и почему он важен

OID — числовой идентификатор алгоритма или набора параметров. Например, 1.2.643.7.1.1.1.1 означает ГОСТ Р 34.10-2012 с 256-битным ключом, а 1.2.643.7.1.1.3.2 обозначает ГОСТ Р 34.10-2012/256 с соответствующим хэшированием. Из-за похожих номеров иногда путают алгоритм ключа и алгоритм подписи. Они могут быть разными полями одного сертификата.

Для системного администратора полезно знать следующее:

  • неизвестный OID не всегда означает испорченный сертификат; иногда программе не хватает профиля;
  • понятный OID ещё не гарантирует, что установленный криптографический механизм выполняет нужный алгоритм;
  • наличие сертификата ещё не подтверждает цепочку доверия;
  • тестовые параметры могут корректно читаться, но не предназначены для рабочей инфраструктуры;
  • неправильная длина ключа или повреждённые параметры — это ошибка формата, которую не следует исправлять отключением проверки.

Как проверить полученный сертификат

Для пользовательских файлов создайте каталог со стандартными ограничениями доступа:

mkdir -p "$HOME/gost-cert-check"
chmod 700 "$HOME/gost-cert-check"
cp /путь/к/полученному/сертификату.cer "$HOME/gost-cert-check/partner.cer"
cd "$HOME/gost-cert-check"
file partner.cer

Расширение .cer не определяет однозначно формат. Сертификат может быть двоичным DER или текстовым PEM. Проверку выполняйте последовательно:

# Для двоичного DER:
openssl x509 -inform DER -in partner.cer \
  -noout -subject -issuer -serial -dates

# Для текстового PEM:
openssl x509 -inform PEM -in partner.cer \
  -noout -subject -issuer -serial -dates

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

Для независимого взгляда на структуру:

openssl asn1parse -inform DER -in partner.cer -i | head -80

Если файл в PEM, используйте -inform PEM. Команда показывает элементы ASN.1; она не проверяет подпись УЦ и не определяет доверие.

Импорт в GPGSM

gpgsm — пользовательский инструмент GnuPG для X.509 и CMS. Импорт сертификата:

gpgsm --import partner.cer
gpgsm --list-keys

Чтобы не смешивать рабочее хранилище с испытаниями, администратор может использовать отдельный каталог GnuPG:

TEST_HOME=$(mktemp -d)
chmod 700 "$TEST_HOME"
GNUPGHOME="$TEST_HOME" gpgsm --import partner.cer
GNUPGHOME="$TEST_HOME" gpgsm --list-keys

Проверка такого импорта демонстрирует, что GPGSM смог обработать файл в выбранной сборке. Она не подтверждает подлинность сертификата и не должна автоматически включать доверие к новому УЦ. После испытания удаляйте временный каталог только если в нём нет ключей или иных данных, которые необходимо сохранить.

Проверка доверия — отдельная процедура

Проверяйте имя и реквизиты УЦ, полный путь до корневого сертификата, сроки, допустимость ключа для нужной операции, наличие ограничений, статус отзыва и актуальность времени на системе. Иногда сертификат корректно разбирается, но цепочка не построена из-за отсутствующего промежуточного УЦ. Иногда цепочка есть, но политика предприятия не разрешает этому УЦ подписывать соответствующие документы.

Не включайте недоверенный сертификат в глобальные корневые доверенные УЦ только ради успешного теста. Не отключайте проверки срока действия и отзыва, чтобы «исправить» проблему несовместимости.

Когда нужен закрытый ключ

Для проверки чужой подписи обычно достаточно сертификата подписанта, данных и необходимой цепочки УЦ. Для создания подписи нужен собственный закрытый ключ. Он может храниться в программном хранилище, токене или другом средстве криптографической защиты. libksba не содержит такой ключ и не делает его экспортируемым. Обработка X.509 не равнозначна поддержке определённого PKCS#11-токена.

Ограничения

Патч не означает поддержку каждого существующего или нестандартного набора эллиптических параметров. Отображаемое символьное имя кривой зависит и от вычислительной библиотеки; некоторые незнакомые идентификаторы сохраняются строкой OID. Это позволяет диагностировать документ, но не гарантирует криптографическую операцию. Для сертификатов, созданных корпоративными УЦ или КриптоПро, следует проводить проверку на реальных файлах конкретного партнёра.

Подробнее: подписи CMS, эксплуатация, совместимость. Первичные спецификации: RFC 4491, RFC 9215.