Статус: Активный участник
Группы: Участники
Зарегистрирован: 04.04.2008(UTC)
Сообщений: 43
Откуда: Новосибирск
|
Спасибо за ваши ответы! Но всё-таки нам очень надо при установке SSL-соединения выбирать сертификат по названию контейнера. Может быть я чего-то не понимаю, но как вообще предполагается использовать выбор ключа по паролю? Сейчас у нас ситуация следующая. Мы используем SSLContext. Мы вынуждены выставить требования к нашему ПО, чтобы у каждого контейнера был уникальный пароль. При каждом соединении JTLS перебирает все ключи в хранилище и соединений занимает 1000мс(против 30мс для RSA в том же ПО). Может быть я как-то неправильно использую. Есть пример, как это следует правильно использовать в высоконагруженном ПО? Может быть я могу что-нибудь переписать, чтобы сразу нужный контейнер выбирался из хранилища? Подскажите пожалуйста, какие есть варианты.
И ещё вопрос - почему трастменеджер инициализированный хранилищем на самом деле не использует его, а пускает всех клиентов с любыми сертификатами, в частности с самоподписанными которых нет в этом хранилище?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,927  Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 691 раз в 652 постах
|
Автор: Cynepnaxa  Но всё-таки нам очень надо при установке SSL-соединения выбирать сертификат по названию контейнера. Может быть я чего-то не понимаю, но как вообще предполагается использовать выбор ключа по паролю? Сейчас у нас ситуация следующая. Мы используем SSLContext. Мы вынуждены выставить требования к нашему ПО, чтобы у каждого контейнера был уникальный пароль. При каждом соединении JTLS перебирает все ключи в хранилище и соединений занимает 1000мс(против 30мс для RSA в том же ПО). Может быть я как-то неправильно использую.
Еще раз повторю - в JTLS указать конкретный контейнер не выйдет. KeyStore (HDImageStore, в частности) в JCP, в отличие от Sun провайдера (или любого похожего, например, для RSA контейнера формата PKCS12) представляет собой совокупность контейнеров в папке C:\Users\<user>\Application Data\Crypto Pro (/var/opt/cprocsp/keys/<user>), а не отдельный контейнер, поэтому получить какой-либо ключевой ГОСТ-контейнер можно только перечислением их, что и происходит в менеджере ключей. Автор: Cynepnaxa
Есть пример, как это следует правильно использовать в высоконагруженном ПО? Может быть я могу что-нибудь переписать, чтобы сразу нужный контейнер выбирался из хранилища? Подскажите пожалуйста, какие есть варианты.
Такого примера нет. Но, наверно, можно попробовать написать свой менеджер ключей и подсунуть его. Пример своего менеджера: http://codyaray.com/2013...-with-multiple-keystoreshttps://commons.apache.o...eyManagerUtils.java.htmlАвтор: Cynepnaxa И ещё вопрос - почему трастменеджер инициализированный хранилищем на самом деле не использует его, а пускает всех клиентов с любыми сертификатами, в частности с самоподписанными которых нет в этом хранилище? Думаю, это от того, что у вас версия JCP/JTLS 1.0.54. В более поздних версиях исправлен механизм построения цепочки. Отредактировано пользователем 9 июля 2015 г. 14:36:43(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 14.10.2014(UTC) Сообщений: 38 Откуда: Казань Сказал(а) «Спасибо»: 12 раз
Поблагодарили: 1 раз в 1 постах
|
Популярная тема... :) Прошу разрешить также и мои сомнения... В качестве ws-клиента я использую Apache CXF. Для инициализации применяю следующий код: Код:System.setProperty("javax.net.ssl.keyStorePassword","password");
System.setProperty("javax.net.ssl.keyStoreType","HDImageStore");
System.setProperty("javax.net.ssl.trustStorePassword","password");
System.setProperty("javax.net.ssl.trustStoreType","HDImageStore");
System.setProperty("javax.net.ssl.trustStore","C:/_Keystores_/CPROscp/trusted_store");
где HDImageStore настроен в JCP на каталог, в котором хранится единственный контейнер с паролем "password", а в trusted_store лежит самоподписанный сертификат сервера Правильно ли я понимаю, из данного лога: Код:июл 09, 2015 4:18:06 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO: keyStore is :
июл 09, 2015 4:18:06 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO: keyStore type is : HDImageStore
июл 09, 2015 4:18:06 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO: keyStore provider is :
июл 09, 2015 4:18:06 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO: init keystore
июл 09, 2015 4:18:06 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO: defaultStoreProvider =
июл 09, 2015 4:18:06 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO:
июл 09, 2015 4:18:06 PM ru.CryptoPro.JCP.tools.Starter check
INFO: Loading JCP 1.0.54 36641
июл 09, 2015 4:18:06 PM ru.CryptoPro.JCP.tools.Starter check
INFO: JCP loaded.
июл 09, 2015 4:18:06 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO: init keymanager of type GostX509
июл 09, 2015 4:18:07 PM ru.CryptoPro.JCP.tools.AbstractLicense checkSerialHash
INFO: Backward compatibility checking license.
июл 09, 2015 4:18:07 PM ru.CryptoPro.JCP.tools.AbstractLicense checkSerialHash
INFO: Check license with company name: true
июл 09, 2015 4:18:07 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO: trustStore is: C:/_Keystores_/CPROscp/trusted_store
июл 09, 2015 4:18:07 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO: trustStore type is : HDImageStore
июл 09, 2015 4:18:07 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO: trustStore provider is :
июл 09, 2015 4:18:07 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO: init truststore
июл 09, 2015 4:18:07 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO: init trustmanager of type GostX509
июл 09, 2015 4:18:07 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO: init context...
июл 09, 2015 4:18:07 PM ru.CryptoPro.ssl.SSLContextImpl d
INFO: Context inited.
то ssl-контекст проинициализировался правильно? Смущают пустой вывод в строках, типа: и возникающая далее ошибка: Код:java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
Отредактировано пользователем 9 июля 2015 г. 16:34:44(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,927 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 691 раз в 652 постах
|
1) Включите более детальное логирование для SSLLogger.
2) Инициализация по логу выполнилась, но не факт, что apache не создает какой-нибудь SSLContext по умолчанию, в который (по умолчанию) не передается хранилище доверенных сертификатов, потому the trustAnchors parameter must be non-empty. |
|
 1 пользователь поблагодарил Евгений Афанасьев за этот пост.
|
est412 оставлено 09.07.2015(UTC)
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 14.10.2014(UTC) Сообщений: 38 Откуда: Казань Сказал(а) «Спасибо»: 12 раз
Поблагодарили: 1 раз в 1 постах
|
Вы правы! Углубленное логирование показало, что сначала загружаются ключи и сертификаты из правильных мест, а потом из каких-то мест по-умолчанию... Похоже, установка параметров контекста через системные переменные не подходит. Придётся, видимо, настраивать через Spring-конфигурацию (элемент <http:conduit>). Нет ли примера, как это правильно сделать? Для провайдера по-умолчанию с контейнером JKS такая настройка понятна и работает, но с КриптоПро возникли сложности, в связи с чем и попытался переключиться на системные переменные... Отредактировано пользователем 9 июля 2015 г. 17:56:24(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,927 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 691 раз в 652 постах
|
Автор: est412 Вы правы!
Нет ли примера, как это правильно сделать?
Для провайдера по-умолчанию с контейнером JKS такая настройка понятна и работает, но с КриптоПро возникли сложности, в связи с чем и попытался переключиться на системные переменные... К сожалению, нет. Посмотрите, может, можно как-нибудь SSLContext создать/передать. Главное отличие от JKS - что нет пути к файлу контейнера, должно быть keyStore.load(null, null), а не, например, keyStore.load(new FileInputStream("файл"), password). Отредактировано пользователем 9 июля 2015 г. 18:15:05(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 04.04.2008(UTC)
Сообщений: 43
Откуда: Новосибирск
|
Автор: afev поэтому получить какой-либо ключевой ГОСТ-контейнер можно только перечислением их, что и происходит в менеджере ключей А я правильно понимаю, что подняв один раз серверный сокет, менеджер ключей всё равно при каждом соединении перечитывает все хранилища в поиска ключа, к которому пароль подойдёт?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,927 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 691 раз в 652 постах
|
По идее, он перечитывается (пересоздается) при создании и инициализации SSLContext. Либо, если используются System.setProperty и SSLSocketFactory из JTLS, то он создается один раз и затем кэшируется. Поэтому, если стабильно используется только одно доверенное хранилище и какой-то определенный контейнер, то лучше использовать System.setProperty для их задания. |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 04.04.2008(UTC)
Сообщений: 43
Откуда: Новосибирск
|
Странная ситуация возникла. Раньше устанавливали хранилища и пароли через systemProperties и сокет получали из фабрики по-умолчанию - всё более-менее работало. Сейчас вместо этого инициализируем SslContext,и Key/TrustManager всё по правилам - на Windows Отладили, ставим на Unix - ошибка java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty. В расширенных логах вижу: Код:Jul 15, 2015 5:23:54 PM ru.CryptoPro.JCP.pref.JCPPref get
CONFIG: System Preference Node: /ru/CryptoPro/JCP/KeyStore/HDImage.HDImageStore_class_default=/var/CPROcsp/keys/${user.name}
Jul 15, 2015 5:23:56 PM ru.CryptoPro.ssl.D a
FINE:
%% adding as trusted certificates %%
--------
/ru/CryptoPro/JCP/KeyStore/HDImage.HDImageStore_class_default=/var/CPROcsp/keys/${user.name} - не имеет отношения к нашему ПО. Подскажите пожалуйста что это и как сделать чтобы программа искала там где указано траст менеджеру? Написание своего траст менеджера поможет?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,927 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 691 раз в 652 постах
|
/ru/CryptoPro/JCP/KeyStore/HDImage.HDImageStore_class_default=/var/CPROcsp/keys/${user.name} - это свойство, чье значение - папка с контейнерами, в *nix системе - это /var/cprocsp/keys/${user.name}. К trust store отношения не имеет. Trust manager грузит сертификаты из указанного ему хранилища сертификатов (например, с помощью System.setProperty). Например, trust manager (и key manager) грузится (читаются свойства javax.* из System.xxxProperty), когда создается SSLContext (в случае JTLS - реализация SSLContextImpl).
Приведите пример, как вы свойства задаете. |
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
