Статус: Активный участник
Группы: Участники
Зарегистрирован: 14.11.2019(UTC) Сообщений: 47
Сказал(а) «Спасибо»: 17 раз Поблагодарили: 1 раз в 1 постах
|
Коллеги, день добрый! Возникает ошибка при подписании документа через CAdES plugin Указан неправильный тип поставщика. (0x80090014)История создания сертификата. 1) Ключевая пара и запрос на сертификат формировался средствами библиотеки Bouncy Castle (java), т.к. требовалось указать недефолтные параметры Код:
private KeyPair generateKeyPair()
throws GeneralSecurityException
{
Security.addProvider( new org.bouncycastle.jce.provider.BouncyCastleProvider() );
KeyPairGenerator keyPairGenerator = KeyPairGeneratorSpi.getInstance("ECGOST3410-2012"); // ECGOST3410-2012
// "1.2.643.2.2.35.2", "1.2.643.7.1.1.2.2", "1.2.643.2.2.31.1" - curve, hash, cipher
keyPairGenerator.initialize( new GOST3410ParameterSpec(
new ASN1ObjectIdentifier("1.2.643.2.2.35.2"),
new ASN1ObjectIdentifier("1.2.643.7.1.1.2.2"),
new ASN1ObjectIdentifier("1.2.643.2.2.31.1")
));
KeyPair keyPair = keyPairGenerator.generateKeyPair();
return keyPair;
}
2. Запрос с требуемыми УЦ параметрами был сформирован и по нему был получен сертификат 3. Средствами Bouncy Castle объединил полученный сертификат и приватный ключ в pfx. Он нормально установился в личные сертификаты, читается и он, и путь сертификации. 4. При попытке использовать его в качестве сертификата для подписания на этой строчке (js) Код:var sSignature = yield oSignedData.SignCades(oSigner, cadesplugin.CADESCOM_CADES_BES, false);
возникает ошибка Указан неправильный тип поставщика. (0x80090014)5. При попытке проверить работу плагина на странице https://cryptopro.ru/sites/default/files/products/cades/demopage/cades_bes_sample.html вижу вот такую информацию о провайдере и приватном ключе Цитата:Криптопровайдер: Microsoft Software Key Storage Provider
Ссылка на закрытый ключ: Указан неправильный тип поставщика. (0x80090014) Подскажите, пожалуйста 1) Почему выбирается этот криптопровайдер? Подозреваю, что именно из-за выбора этого КП возникает ош. 0x80090014 - он не поддерживает ГОСТовские алгоритмы? 2) Может ли быть причиной то, что при формировании ключевой пары я использовал BouncyCastleProvider? 3) Или то, что я объединял приватный ключ и полученный сертификат в pfx при помощи этой же библиотеки? 4) Есть ли возможность в bouncy castle явно указать, что в качестве криптопровайра нужно использовать Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider? Где-то в интернете находил информацию, что при подобных ошибках нужно заново сгенерировать ключевую пару средствами КриптоПро и запросить сертификат. Но, как выяснилось ранее, стандартными средствами КриптоПро сформировать ключевую пару и запрос с указанными параметрами алгоритма нельзя ( https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=19238) Заранее большое спасибо за информацию
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602  Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 396 раз в 366 постах
|
Добрый день. Хотелось бы уточнить несколько моментов: 1) это разовая операция генерации или она будет потом повторяться этим же ПО каждый год для каждого пользователя? Если разовая, то наверно можно и этот ключ переконвертировать, а если будет повторяться - лучше все же разобраться как сделать средствами КриптоПро. "1.2.643.2.2" это оиды зарегистрированные именно КриптоПро, вероятность что они не поддерживаются мала, хотя я сам и не пробовал задавать "1.2.643.2.2.35.2" с гост-2012. 2) в приведенной теме не ответа видимого всем - перенесено на портал техподдержки. Вопрос в теме касался именно CAdES плагина, то есть при использовании других средств обращения к криптопровайдеру (CryptoAPI) очень может быть, что данные параметры задать получится. Даже в случае именно веб-генерации логичнее задавать вопрос не про CAdES плагин, а класс CertEnrollment, на котором построены интерфейсы УЦ (хоть он и ограничен IE, но параметров побольше и, например, можно все вместить в приложение HTA). 3) какими средствами устанавливался pfx в личные сертификаты? В теории если это ключ гост-2012, то вопрос только в формате его представления и в том, чтобы сертификат был по оидам совместим с КриптоПро. Если сертификат совместим, то подобрать алгоритмы в pfx теоретически можно. Дамп ASN1 в pfx (сам ключ заменить на многоточие) было бы интересно посмотреть на предмет совместимые там алгоритмы с криптопро или нет. Если не совместимы напрямую (что позволяет правой кнопкой щелкнуть на pfx файле и выбрать установить, а на выходе мастера получить контейнер в формате КриптоПро), но совместимы с универсальным форматом между отечественными криптопровайдерами (pfx использующий только госты), то есть консольная утилита конвертации. Если ни то и ни другое - то возможно действительно проще перегенерировать ключ, так как процесс конвертации будет сложнее.
|
 1 пользователь поблагодарил two_oceans за этот пост.
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 14.11.2019(UTC) Сообщений: 47
Сказал(а) «Спасибо»: 17 раз Поблагодарили: 1 раз в 1 постах
|
День добрый! Кажется, понял, в чем проблема, но пока не могу понять, как ее решить. Думаю, что проблема в том, как я читаю приватный ключ из pem-файла и как объединяю сохраненный ранее приватный ключ и полученный сертификат: Код: public void buildPfx(X509Certificate certificate, PrivateKey privateKey) throws KeyStoreException, IOException, CertificateException, NoSuchAlgorithmException, NoSuchProviderException {
String alias = "Test Signer";
X509Certificate[] chain = new X509Certificate[] {
certificate
};
KeyStore keystore = KeyStore.getInstance("PKCS12", "BC");
keystore.load(null, null);
KeyStore.PrivateKeyEntry keyEntry = new KeyStore.PrivateKeyEntry(
privateKey,
chain
);
keystore.setEntry(alias,
keyEntry,
new KeyStore.PasswordProtection(this.getPassword().toCharArray())
);
keystore.store(new FileOutputStream(this.getPfxPath()), this.getPassword().toCharArray());
}
В этом случае формируется key entry в Microsoft Software Key Storage Provider, а затем из него экспортируется pfx. В итоге ГОСТ не работает. Поставил JCP, заменил процесс формирования keyStore: Код:KeyStore keystore = KeyStore.getInstance("HDImageStore", "JCP");
В этом случае получаю ошибку на setEntry: java.security.KeyStoreException: key is not GostPrivateKey or GostExchPrivateKeyЧтение приватного ключа реализую так: Код: public PrivateKey getPrivateKey() throws IOException, NoSuchAlgorithmException, InvalidKeySpecException, NoSuchProviderException, KeyManagementException {
PemObject object = this.readPEMObject(this.getKeyPath());
PKCS8EncodedKeySpec privateKeySpec = new PKCS8EncodedKeySpec(object.getContent());
PrivateKey key = KeyFactory.getInstance("ECGOST3410-2012")
.generatePrivate(privateKeySpec);
return key;
}
Пробовал здесь использовать JCP, но, насколько я понял, он не умеет загружать приватные ключи из pem-файлов. Или все-таки умеет? Предполагаю, что если бы мне удалось прочитать приватный ключ из pem-файла методами JCP, то и при объединении не было бы проблем. P.S. Странно, но certutil на pfx выдает "Плохие данные", но при этом сертификат из этого же pfx устанавливается в личные сертификаты
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602  Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 396 раз в 366 постах
|
Есть вроде бы вариант использовать PFXSTORE, но вероятно также будет заморочка с алгоритмами в pfx. https://www.cryptopro.ru...aspx?g=posts&t=17499Предположу, что может помочь Openssl + модуль (engine) гост (с гитхаба или от пробного магпро, так как модули от криптопро не считывают pem, а старый Криптокома не поддерживает гост-2012). Закладка на тему где-то затерялась, но есть цитата аналогичного случая.
Цитата:В данном pfx/p12 для шифрования секретных ключей используются иностранные алгоритмы, не поддерживаемые нашей утилитой. В openssl для того, чтобы для шифрования ключей использовались алгоритмы ГОСТ, следует это указывать явно, например, так: Код:openssl -engine gost -export -inkey seckey.pem -in cert.pem -out pkcs12.p12 -password pass:12345 -keypbe gost89 -certpbe gost89 -macalg md_gost12_256
Полученный таким образом контейнер должен приниматься нашей утилитой. Потом еще немного другой вариант и цитата как импортировать утилитой Код:https://www.cryptopro.ru/sites/default/files/public/p12tocp.zip
p12util.x64.exe -p12tocp -rdrfolder d:\ -contname 888888 -ex -passcp 12345678 -passp12 12345678 -infile d:\vipnet2012.p12 -noMACVerify
p12util.x64.exe -p12tocp -rdrfolder d:\ -contname 888888 -ex -passcp 12345678 -passp12 12345678 -infile d:\vipnet2012.p12
|
 1 пользователь поблагодарил two_oceans за этот пост.
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 14.11.2019(UTC) Сообщений: 47
Сказал(а) «Спасибо»: 17 раз Поблагодарили: 1 раз в 1 постах
|
Коллеги, день добрый!
Перепробовали все, в т.ч. openssl с разными engine. Результат такой же - либо не тот провайдер, либо не ГОСТ.
Т.к. цель была записать все это на Рутокен - переписал все с использованием их библиотек - и формирование запроса, и импорт сертификата. Все получилось)
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close