Статус: Активный участник
Группы: Участники
Зарегистрирован: 10.06.2014(UTC) Сообщений: 65  Сказал(а) «Спасибо»: 5 раз
|
Автор: afev  Автор: HelenKlimova Ключ ГОСТ 34.10-2001. Закрытый ключ с каким алгоритмом отображается (открыть контейнер в панели JCP, выбрать "Ключ" в контейнере, справа на вкладке "Ключ" - тип и алгоритм ключа)? GOST3410DH
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,005 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
Попробуйте задать пароль на контейнер.
Какую версию JCP (JTLS) вы используете? |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 10.06.2014(UTC) Сообщений: 65 Сказал(а) «Спасибо»: 5 раз
|
Автор: afev Попробуйте задать пароль на контейнер.
Какую версию JCP (JTLS) вы используете? Пробовали задавать, он и сейчас с паролем. Пока тестируем триальное Крипто-Про 2.0.37283 С другими партнерами аналогичное соединение работает нормально. А тут что-то непонятное. Не надо же никаких дополнительных OID для ключа?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,005 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
Условия подбора контейнера (-ов) следующие: I. инициализация KeyManager 1) составляется список контейнеров, которым подходит пароль password 2) проверяется наличие цепочки сертификатов в контейнере 3) проверяется сертификат подписи на корректность срока действия II. Во время процедуры согласования: 1) Декодируются список поддерживаемых алгоритмов и список distinguished names из certificate request сервера, получается список issuers 2) по каждому из алгоритмов (обычно достаточно GOST3410) выбирается список контейнеров (из п.I), издатели сертификатов которых входят в issuers, а также сертификаты должны содержать 1.3.6.1.5.5.7.3.2 (client auth) 3) получаем закрытый ключ и сертификат, проверяем открытый и закрытый ключи на соответствие 4) формируем ответное certificate message 5) если пп. 2-4 не выполнились, то выбирается любой подходящий по алгоритму контейнер (из п.I), при этом генерируется эфемерная пара и формруется certificate verify. Попробуйте JCP 2.0.37538. Приложение работает под тем пользователем, у которого в папке Crypto Pro лежат контейнеры? Отредактировано пользователем 11 июня 2014 г. 11:01:48(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 10.06.2014(UTC) Сообщений: 65 Сказал(а) «Спасибо»: 5 раз
|
Автор: afev Попробуйте JCP 2.0.37538. Спасибо, попробуем Автор: afev Приложение работает под тем пользователем, у которого в папке Crypto Pro лежат контейнеры? Пока приложением это сложно назвать, мы делаем юнит-тесты для проверки работоспособности соединения и отправки-получения данных. Контейнеры лежат в папке у меня на компьютере, я - администратор, проблем с правами нет. Тем более, что остальные такие же контейнеры работают нормально.
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 10.06.2014(UTC) Сообщений: 65 Сказал(а) «Спасибо»: 5 раз
|
Автор: afev Условия подбора контейнера (-ов) следующие:
I. инициализация KeyManager
1) составляется список контейнеров, которым подходит пароль password
2) проверяется наличие цепочки сертификатов в контейнере
3) проверяется сертификат подписи на корректность срока действия
II. Во время процедуры согласования:
1) Декодируются список поддерживаемых алгоритмов и список distinguished names из certificate request сервера, получается список issuers
2) по каждому из алгоритмов (обычно достаточно GOST3410) выбирается список контейнеров (из п.I), издатели сертификатов которых входят в issuers, а также сертификаты должны содержать 1.3.6.1.5.5.7.3.2 (client auth)
3) получаем закрытый ключ и сертификат, проверяем открытый и закрытый ключи на соответствие
4) формируем ответное certificate message
5) если пп. 2-4 не выполнились, то выбирается любой подходящий по алгоритму контейнер (из п.I), при этом генерируется эфемерная пара и формруется certificate verify. Вот такой вопрос. Судя по нашему логу, получается, что п 2-4 не выполнились, т.к. генерируется эфемерная пара. Список контейнеров выбирается, мы их видим. И они даже могут быть с паролем. Вот дальше - возможно ли невыполнение пункта 3, например? Если нет, то почему ответное certificate message не формируется? Может быть, какую-то Property установить? Что может мешать соединению, если у нас правильный сертификат, по ГОСТ, выпущенный совсем недавно, и издатель присутствует в списке? Что должно быть в контейнере? Мы пробовали просто с сертификатом, и с добавленной цепочкой сертификат-УЦ. Что должно быть в trust store? Мы добавляем туда сертификат УЦ, пробовали еще добавлять серверный сертификат. WARNING: %% No alias is match значит, что сервер не знает (не может найти) информацию о нас? Или мы не можем ему нашу информацию выдать? Попробуем поменять версию Крипто-про, но почему-то кажется, что дело не в этом.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,005 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
Автор: HelenKlimova
Вот дальше - возможно ли невыполнение пункта 3, например?
В случае ошибки должно быть сообщение типа "<alias>: private key test failed". Автор: HelenKlimova
Если нет, то почему ответное certificate message не формируется?
Возможно, поможет обновление до JCP/JTLS 2.0.37538, т.к. была ошибка в JCP 2.0.37363 - changelog: * tls: исправлена ошибка: client auth requested воспринимался, как client auth required (JCP-296) Автор: HelenKlimova
Что должно быть в trust store? Мы добавляем туда сертификат УЦ, пробовали еще добавлять серверный сертификат.
Только корневые сертификаты, например, издателя серверного сертификата. Автор: HelenKlimova
WARNING: %% No alias is match значит, что сервер не знает (не может найти) информацию о нас? Или мы не можем ему нашу информацию выдать?
означает, что не найден подходящий контейнер для обмена с сервером (ни один из сертификатов не прошел проверки). P.S. Автор: HelenKlimova
С другими партнерами аналогичное соединение работает нормально. А тут что-то непонятное.
Сертификаты в контейнере для несрабатывающего примера и в работающем случае схожи (параметры, key usage и т.п.)? Попробуйте включить логирование level=ALL для SSLLogger и потом прикрепите лог. Отредактировано пользователем 11 июня 2014 г. 17:28:27(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 10.06.2014(UTC) Сообщений: 65 Сказал(а) «Спасибо»: 5 раз
|
Автор: afev
Возможно, поможет обновление до JCP/JTLS 2.0.37538, т.к. была ошибка в JCP 2.0.37363 -
changelog: * tls: исправлена ошибка: client auth requested воспринимался, как client auth required (JCP-296)
Переставили версию Крипто-про, соединиться по крайней мере с тестовым сервером удалось. Большое спасибо, что уделили внимание нашему вопросу. Хотя непонятно, почему соединение получилось только с последней версией. Пробовали на более ранних, в т.числе на 1.0.57
|
|
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 21.11.2022(UTC)
Сообщений: 8
Сказал(а) «Спасибо»: 3 раз
|
Добрый день. Столкнулись с тем, что ни один из контейнеров во время процедуры согласования с сервером не был выбран: Цитата:
25-11-2022 15:28:45.264 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - *** ServerHelloDone
25-11-2022 15:28:45.265 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - Certificate request received...
25-11-2022 15:28:45.265 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - Search for client containers with GOST algorithms...
25-11-2022 15:28:45.265 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - Search for client containers with any GOST algorithm...
25-11-2022 15:28:45.265 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - %% getting aliases for Client
25-11-2022 15:28:45.265 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - %% checking alias: XXXXXXX...
25-11-2022 15:28:45.265 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - %% check public key algorithm ignored.
25-11-2022 15:28:45.265 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - %% signature algorithm not found.
25-11-2022 15:28:45.266 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - %% check extended key usage of Client, size: 2...
25-11-2022 15:28:45.266 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - %% Extended key usage found and verified.
25-11-2022 15:28:45.266 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - %% check credential issuers...
25-11-2022 15:28:45.266 WARN ru.CryptoPro.ssl.SSLLogger.error - %% No alias is match
25-11-2022 15:28:45.266 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - Appropriate client aliases not found.
25-11-2022 15:28:45.266 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - Containers not found.
25-11-2022 15:28:45.266 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - No appropriate cert was found.
25-11-2022 15:28:45.267 DEBUG ru.CryptoPro.ssl.SSLLogger.subTrace - *** Certificate message
Сертификат точно содержит 1.3.6.1.5.5.7.3.2 (client auth). Проверяли на jcp-2.0.40035 и на java-csp-5.0.41975 + CSP 5. Результат одинаковый. Цитата:
Условия подбора контейнера (-ов) следующие:
I. инициализация KeyManager
1) составляется список контейнеров, которым подходит пароль password
2) проверяется наличие цепочки сертификатов в контейнере
3) проверяется сертификат подписи на корректность срока действия
II. Во время процедуры согласования:
1) Декодируются список поддерживаемых алгоритмов и список distinguished names из certificate request сервера, получается список issuers
2) по каждому из алгоритмов (обычно достаточно GOST3410) выбирается список контейнеров (из п.I), издатели сертификатов которых входят в issuers, а также сертификаты должны содержать 1.3.6.1.5.5.7.3.2 (client auth)
3) получаем закрытый ключ и сертификат, проверяем открытый и закрытый ключи на соответствие
4) формируем ответное certificate message
5) если пп. 2-4 не выполнились, то выбирается любой подходящий по алгоритму контейнер (из п.I), при этом генерируется эфемерная пара и формруется certificate verify.
Подскажите, что имеется ввиду под фразой из п5. "выбирается любой подходящий по алгоритму контейнер (из п.I)"? Я правильно понимаю, что в любом случае какой-то контейнер должен быть выбран на шаге 5, даже если сервер к которому мы пытаемся подключиться, не прислал в списке issuers сертификат издателя для нашего клиентского сертификата? Или наличие нашего CA в списке issuers обязательно для выбора контейнера?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,005 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
"Или наличие нашего CA в списке issuers обязательно для выбора контейнера?" - да.
Лог при проверке контейнера обрывается на "%% check credential issuers..." - не прошла проверка по издателю. Такое бывает, если цепочка клиента состоит, например, из 3-х сертификатов (USER-CA-ROOT), а в вашем ключевом контейнере - только сертификат ключа (USER). Сервер шлет список, в котором ROOT, но издатель USER - CA, его нет в списке. Если так, установите в контейнер всю цепочку сертификатов клиента (p7b). |
|
 1 пользователь поблагодарил Евгений Афанасьев за этот пост.
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
