ГОСТ OpenSSL и КриптоПро: совместимость ключей и PFX¶

НАЙС.ОС позволяет использовать OpenSSL для работы с ГОСТ-ключами, сертификатами и контейнерами. При обмене с КриптоПро CSP необходимо учитывать формат контейнера: стандартный PFX по RFC 9337/9548 и исторический PFX с собственной схемой защиты закрытого ключа — это разные варианты.

Разработчики gost-engine отдельно описывают совместимость с КриптоПро, включая импорт стандартных контейнеров и чтение проприетарного key bag при помощи Provider.

1. Какие файлы участвуют в обмене¶

Файл	Содержимое
`.key`/`.pem`	Закрытый ключ в кодировке OpenSSL/PKCS#8
`.crt`/`.cer`	Сертификат X.509; закрытого ключа внутри нет
`.pfx`/`.p12`	Ключ + сертификат + цепочка, обычно с паролем
Контейнер CSP	Хранилище КриптоПро и его метаданные

Перед передачей PFX согласуйте допустимость экспорта закрытого ключа: отдельные ключи могут создаваться неэкспортируемыми.

2. Создать PFX в НАЙС.ОС для передачи¶

openssl pkcs12 -export \
  -inkey private.pem -in certificate.crt \
  -keypbe kuznyechik-ctr-acpkm \
  -certpbe kuznyechik-ctr-acpkm \
  -macalg md_gost12_512 \
  -name 'NiceOS GOST' \
  -out niceos-for-import.pfx

На стороне принимающей системы проверьте успешную привязку сертификата к закрытому ключу. В испытаниях upstream используется certmgr -install -pfx и проверяется PrivateKey Link: Yes.

Для автоматизации не размещайте пароль PFX в истории Bash, журнале CI или аргументе pass:.

3. Старые контейнеры КриптоПро¶

Устаревшие контейнеры, выгружаемые инструментом certmgr -export -pfx, могут использовать собственный алгоритм защиты key bag с OID:

1.2.840.113549.1.12.1.80

Эта кодировка не является обычным PBE из RFC 7292. В upstream gost-engine для неё реализовано чтение при использовании Provider; формирование новых PFX в таком проприетарном формате не предусмотрено. Для нового экспорта используйте стандартный профиль, согласованный с получателем.

4. Профиль Provider для чтения контейнера КриптоПро¶

В закрытой лаборатории создайте конфигурацию. Каталог модуля берётся из openssl version -m:

mkdir -p ~/gost-lab/cryptopro
cd ~/gost-lab/cryptopro
cat > provider-cryptopro.cnf <<'EOF'
openssl_conf = openssl_init

[openssl_init]
providers = providers

[providers]
default = default_section
legacy = legacy_section
gostprov = gost_section

[default_section]
activate = 1
[legacy_section]
activate = 1
[gost_section]
activate = 1
EOF

openssl version -m
rpm -ql openssl-gost-engine | grep gostprov.so

Если gostprov.so не найден автоматически, задайте OPENSSL_MODULES каталогом, где он расположен.

5. Посмотреть PFX из КриптоПро¶

OPENSSL_CONF="$PWD/provider-cryptopro.cnf" \
  openssl pkcs12 -in cryptopro-export.pfx -info -noout

Введите пароль через интерактивный запрос. Сначала убедитесь, что контейнер распознаётся и содержит правильный сертификат.

6. Извлечь сертификат без закрытого ключа¶

OPENSSL_CONF="$PWD/provider-cryptopro.cnf" \
  openssl pkcs12 -in cryptopro-export.pfx \
  -nokeys -out imported-certificate.pem

openssl x509 -in imported-certificate.pem -noout \
  -subject -issuer -serial -dates -fingerprint

7. Экспортировать закрытый ключ из разрешённого контейнера¶

umask 077
OPENSSL_CONF="$PWD/provider-cryptopro.cnf" \
  openssl pkcs12 -in cryptopro-export.pfx \
  -nocerts -noenc -out imported-private.pem
chmod 600 imported-private.pem

Эту операцию выполняйте только если экспорт прямо разрешён регламентом владельца ключа. Файл imported-private.pem — чрезвычайно чувствительный объект; после переноса его нужно защищать не слабее исходного хранилища CSP.

8. Проверить, что сертификат и ключ совпадают¶

openssl pkey -in imported-private.pem -pubout -outform DER > key.der
openssl x509 -in imported-certificate.pem -pubkey -noout \
  | openssl pkey -pubin -outform DER > cert.der
cmp key.der cert.der && echo 'Привязка ключа и сертификата корректна'

9. Серийный номер и отпечаток сертификата¶

При переносе сравнивайте сертификат на обеих сторонах:

openssl x509 -in imported-certificate.pem \
  -noout -serial -fingerprint -sha1
openssl x509 -in imported-certificate.pem \
  -noout -fingerprint -sha256

Указанный SHA-1 используется только как формат отпечатка для сопоставления сертификатов, когда его применяет инструмент КриптоПро; это не рекомендация подписывать данные SHA-1.

10. Как понять причину несовместимости¶

Признак	Проверка
`unknown pbe algorithm`	OID key bag, провайдеры `default/legacy/gostprov`
`cipher has no object identifier`	PBE-интеграция OpenSSL; обновления стека и выбранный режим
Нет закрытого ключа после импорта	Разрешённость экспорта; `PrivateKey Link` на стороне CSP
Сертификат читается, ключ не читается	Отдельный алгоритм PBE key bag, пароль, ограничения контейнера
Ключ импортирован, подпись не проверяется	OID кривой, digest, исходные байты, открытый ключ
Сертификат не принимается	Назначение KeyUsage/EKU, цепочка УЦ и политика системы

11. Минимальный протокол проверки миграции¶

Сохранить исходный контейнер и его резервную копию в защищённом хранилище.
Зафиксировать сертификатный отпечаток и OID алгоритмов.
На временном стенде проверить расшифрование и извлечение сертификата.
Сверить открытые ключи из исходного контейнера, импортированного ключа и сертификата.
Подписать контрольный файл и проверить подпись на обеих сторонах.
Сверить права, владельца, условия экспорта и дату замены ключей.
Лишь после успешного обмена переключать рабочий сервис.

12. Указатели на исходные тесты¶

В репозитории upstream сценарии находятся в docker/dev_pkcs12, включая проверки обмена Engine → CryptoPro CSP и чтение CryptoPro keybag через Provider. Это полезные примеры организации испытаний, а не обязательная установка КриптоПро на каждый сервер НАЙС.ОС.

Связанные руководства: PKCS#12, форматы ключей, защита ключей, диагностика.