Closed emejibka closed 1 year ago
Сможете приложить сертификат с ключом, на котором воспроизводится ошибка?
Так как ошибка при открытии ключа - возможные проблемы - нет доступа (прав) к закрытому ключа для пользователя, истёк срок действия закрытого ключа. Проверить это можно на клиенте через утилиту csptest (протестировать соответствующий контейнер закрытого ключа).
Могу, но не публично, Напишите почту.
Проверить это можно на клиенте через утилиту csptest (протестировать соответствующий контейнер закрытого ключа).
Проверяли, ошибок нет, сейчас приложу вывод.
/opt/cprocsp/bin/amd64/certmgr -list -thumbprint bd545df6eacf88bcb14365ac08948c6e65bdf011
Certmgr 1.1 (c) "Crypto-Pro", 2007-2021.
Program for managing certificates, CRLs and stores.
=============================================================================
1-------
Issuer : E=SupportIIT@infotecs.ru, STREET="ул. Мишина, д. 56, стр. 2, эт. 2, пом. IX, ком. 11", C=RU, S=77 г. Москва, L=Москва, O="Акционерное Общество ""ИнфоТеКС Интернет Траст""", OGRN=1027739113049, INNLE=7743020560, CN="АО ""ИИТ"""
Subject : E=***, C=RU, S=***, L=***, G=***, SN=***, SNILS=***, INN=***, CN=***
Serial : 0x01D89758DB5EA9C0000A9E9A00060002
SHA1 Thumbprint : bd545df6eacf88bcb14365ac08948c6e65bdf011
SubjKeyID : 438dca4528108897794b1508858fbc6832cc8ea9
Signature Algorithm : ГОСТ Р 34.11-2012/34.10-2012 256 бит
PublicKey Algorithm : ГОСТ Р 34.10-2012 256 бит (512 bits)
Not valid before : 14/07/2022 08:08:08 UTC
Not valid after : 14/07/2023 08:08:08 UTC
PrivateKey Link : Yes
Container : HDIMAGE\\wqaqgvda.000\612C
Provider Name : Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider
Provider Info : Provider Type: 80, Key Spec: 1, Flags: 0x0
Identification Kind : Personal presence
OCSP URL : http://cades.iitrust.ru:8777/ocsp
OCSP URL : http://193.162.30.68:8777/ocsp
CA cert URL : http://uc1.iitrust.ru/uc/CA-IIT-(K3)-2022.cer
CA cert URL : http://uc2.iitrust.ru/uc/CA-IIT-(K3)-2022.cer
CA cert URL : http://193.162.30.86/uc/CA-IIT-(K3)-2022.cer
CA cert URL : http://193.162.30.76/uc/CA-IIT-(K3)-2022.cer
CDP : http://uc1.iitrust.ru/uc/CA-IIT-(K3)-2022.crl
CDP : http://uc2.iitrust.ru/uc/CA-IIT-(K3)-2022.crl
CDP : http://193.162.30.86/uc/CA-IIT-(K3)-2022.crl
CDP : http://193.162.30.76/uc/CA-IIT-(K3)-2022.crl
CDP : https://uc1.iitrust.ru/uc/CA-IIT-(K3)-2022.crl
CDP : https://uc2.iitrust.ru/uc/CA-IIT-(K3)-2022.crl
Extended Key Usage : 1.3.6.1.5.5.7.3.2 Проверка подлинности клиента
1.3.6.1.5.5.7.3.4 Защищенная электронная почта
=============================================================================
[ErrorCode: 0x00000000]
/opt/cprocsp/bin/amd64/csptest -keyset -check -cont 'HDIMAGE\\wqaqgvda.000\612C'
CSP (Type:80) v5.0.10008 KC1 Release Ver:5.0.12000 OS:Linux CPU:AMD64 FastCode:READY:AVX.
AcquireContext: OK. HCRYPTPROV: 9163283
GetProvParam(PP_NAME): Crypto-Pro GOST R 34.10-2012 KC1 CSP
Container name: "***"
Check header passed.
Signature key is not available.
Exchange key is available. HCRYPTKEY: 0x8d6ac3
Symmetric key is not available.
UEC key is not available.
License: Cert without license
Check container passed.
Check sign passed.
Check verify signature on private key passed.
Check verify signature on public key passed.
Check import passed.
Certificate in container matches AT_KEYEXCHANGE key.
Keys in container:
exchange key
Extensions:
OID: 1.2.643.2.2.37.3.10
PrivKey: Not specified - 13.01.2024 11:37:17 (UTC)
Total: SYS: 0.000 sec USR: 0.010 sec UTC: 0.080 sec
[ErrorCode: 0x00000000]
Отправил, пароль на архив C3S9kbvHYTvidjAZC8gc
Что-нибудь ещё нужно?
Пока нет.
Проблема в кириллической кодировке (1251) имени контейнера. При подписи получаем имя контейнера через CryptGetProvParam, получаем массив байт в 1251, но читаем его как ASCII, получаем кракозябры, пытаемся открыть контейнер с кривым именем - создаём новый контейнер вместо обращения к существующему - падаем с ошибкой.
Проблема только на Linux.
Место - GetStringProvParam
@emejibka Проблему воспроизвели и локализовали, спасибо. В ближайшее время постараемся поправить. За статусом можно следить тут.
Имя контейнера можно задать при установке сертификата?
В зависимости от того, как устанавливается сертификат.
Если сертификат устанавливается из pfx с созданием контейнера - то при установке запрашивается имя создаваемого контейнера.
Если сертификат устанавливается из контейнера - то имя контейнера остаётся то, какое было указано в нём. Поможет только копирование контейнера в новый с другим именем.
Как я понимаю у вас второй вариант (контейнер + сертификат в контейнере).
Если установка сертификата из контейнера - имя контейнера хранится в name.key в формате asn1. Можно записать туда имя без кириллических символов - тогда работа с контейнером будет корректной (не забыть поменять длину в asn1 теге),
Или просто удалить name.key перед установкой контейнера, тогда имя контейнера будут соответствовать имени папки.
Т.е. срочный "грязный фикс" для клиента будет таким - сохранить файлы контейнера, удалить контейнер через csptest, удалить файл name.key, установить контейнер с сертификат из него.
Как я понимаю у вас второй вариант (контейнер + сертификат в контейнере).
Не, на клиенте делаем экспорт сертификата в pfx, на сервере импортируем его с помощью команды
certmgr -install -pfx -file "путь к файлу" -silent -pin "пароль"
Через certmgr, судя по всему, не задаётся имя контейнера, а берётся из серта... Тогда остаётся такой вариант.
Уже можно попробовать тестовую сборку или ещё рано?
Да, можно пробовать сборку https://ci.appveyor.com/project/CryptoPro/corefx/builds/45372589
N.B. В текущей версии используется рантайм 3.1.30. Возможно придётся установить соотвествующий рантайм и SDK.
Спасибо, с обновлением ошибка не воспроизводится
Windows работает и так, понимает, что там 1251
.
Для Linux проблема была в том, что csp возвращала 1251
, но дотнет работал с ASCII
. В результате получали кракозябры + испорченные байте (т.к. ascii заменял непечатные символы). UTF8
, UTF16
, UTF7
- давали аналогичный результата.
Решение - по умолчанию используем на Linux кодировку Latin1
, которая умеет декодировать любой массив байт. В результате хотя бы имеем возможность открыть контейнер, имя которого получено из сертификата с использованием GetProvParam
(да, в cspParams
будут кракозябры, но CryptAcqureContext
на вход получит нужный массив байт, так как Latin1 не портит байты).
Если же на Linux уже зарегистрирована кодировка 1251
- используем её (делается отдельно через пакет System.Text.Encoding.CodePages
с последующим вызовом Encoding.RegisterProvider(CodePagesEncodingProvider.Instance))
, после чего в cspParams
будет попадать корректная строка. (Это же надо использовать, если кто то захочет руками открыть кириллический контейнер)
Статической проперти Encoding.Latin1
в "сборочном" рантайме по каким то причинам нет, но можно пользоваться Latin1 через Encoding.GetEncoding(28591)
, что и делаем.
Тестов не будет, подробнее в связанном запросе для libcore https://gitlab.cp.ru/cloud/misc/libcore/-/issues/12
Здравствуйте. При вычислении подписи на некоторых сертификатах получаем ошибку
код для вычисления подписи
На тестовых сертификатах ошибка не воспроизводится, проявляется только на некоторых сертификатах пользователя и воспроизводится регулярно. Причём прикреплённая подпись формируется без ошибок.
Версия криптопро - 5.0.12000 Сборка corefx из коммита задачи - https://github.com/CryptoPro/corefx/issues/53