Перестал отправляться клиентский сертификат- Page 2

Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Error

2 Страницы<12

Перестал отправляться клиентский сертификат

Опции

Предыдущая тема Следующая тема

what_is_it@inbox.ru		#11 Оставлено : 12 марта 2019 г. 11:38:24(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 27.02.2013(UTC) Сообщений: 38 Откуда: Москва Сказал(а) «Спасибо»: 14 раз Поблагодарили: 11 раз в 9 постах		Не совсем поняла Вас здесь: Цитата: Установите в контейнер всю цепочку вплоть до корневого (p7b) Цепочку сертификатов в контейнер нужно установить на клиенте? Куда и как это правильно сделать, какой контейнер имеется ввиду? Для отправки мы используем сертификат напрямую с ключевого носителя (инициализируем рутокен-store или OCFStore в зависимости от типа ключа) У нас сейчас (на клиенте) вся цепочка установлена в корневые сертификаты локального компьютера (и в используемую клиентским приложением JRE) Или все же речь идет о серверной части? Нам коллеги, которые занимаются серверной частью пишут, что у них все установлено, ссылаясь на то, что авторизация через браузер работает. Но через браузер, как мне казалось,на клиенте смотрятся корневые сертификаты? Не подскажете ссылку на документацию, где об этом хорошо написано? Отредактировано пользователем 12 марта 2019 г. 11:48:05(UTC) \| Причина: Не указана


Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

Евгений Афанасьев		#12 Оставлено : 12 марта 2019 г. 14:10:09(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 704 раз в 665 постах		Автор: what_is_it@inbox.ru Цепочку сертификатов в контейнер нужно установить на клиенте? Да, в клиентский контейнер. Автор: what_is_it@inbox.ru Куда и как это правильно сделать, какой контейнер имеется ввиду? Сделать можно через панель управления JCP, только нужна вся цепочка в виде p7b (в вашем случае, видимо, цепочка из трех сертификатов). Установить в тот контейнер, что используется для соединения с сервером. Автор: what_is_it@inbox.ru Для отправки мы используем сертификат напрямую с ключевого носителя (инициализируем рутокен-store или OCFStore в зависимости от типа ключа) Использует его cpSSL, он читает цепочку из контейнера (из заданного хранилища - рутокен-store или OCFStore) и на текущий момент получает только один сертификат, изданный промежуточным УЦ, которого нет в списке, присылаемом сервером (раньше, вероятно, был там, поэтому работало, потом администратор сервера удалил его из списка Корневых сервера). Если в контейнере будет цепочка, то будет прочитан каждый сертификат в ней, а когда сервер пришлет список доверенных, то клиент убедится, что есть доверие выбранному сертификату, так как корневой из цепочки есть в списке сервера. Автор: what_is_it@inbox.ru У нас сейчас (на клиенте) вся цепочка установлена в корневые сертификаты локального компьютера (и в используемую клиентским приложением JRE) Для java имеет значение только установка в cacerts, и только корневых, и в лучшем случае - для проверки цепочки сервера, а не клиента (в случае cpSSL доверенные находятся не в cacerts, а trust store формата CertStore). Установка сертификатов в My, Root и т.п. актуальна только для CSP. Автор: what_is_it@inbox.ru Но через браузер, как мне казалось,на клиенте смотрятся корневые сертификаты? Не подскажете ссылку на документацию, где об этом хорошо написано? Да, в браузере сертификаты клиента извлекаются из My (к java отношения не имеет). Такой документации, пожалуй, нет, разве что руководства разработчика JTLS из дистрибутива JCP и документация Oracle о JSSE интерфейсе.
		Тех. поддержка База знаний Логирование JCP Логирование JTLS Тест JCP и сбор диаг. информации Скачать JCP, JCSP и JTLS Скачать Android CSP + SDK

1 пользователь поблагодарил Евгений Афанасьев за этот пост.		what_is_it@inbox.ru оставлено 13.03.2019(UTC)
Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

what_is_it@inbox.ru		#13 Оставлено : 13 марта 2019 г. 10:59:26(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 27.02.2013(UTC) Сообщений: 38 Откуда: Москва Сказал(а) «Спасибо»: 14 раз Поблагодарили: 11 раз в 9 постах		Разобрались. Проблема была в том, что на ключевом носителе была, видимо, неправильно установлена цепочка сертификатов. Исправили так: 1. Экспортировали сертификат с контейнера на жесткий диск 2. С помощью мастера экспортировали сертификат вместе со всей цепочкой в файл p7b 3. Перезаписали через панель JCP эту цепочку обратно в контейнер Отредактировано пользователем 13 марта 2019 г. 12:30:29(UTC) \| Причина: Не указана


Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

ShmakovAA		#14 Оставлено : 10 декабря 2021 г. 13:15:45(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 07.12.2020(UTC) Сообщений: 2		Добрый день! Столкнулись с аналогичной проблемой. Нюанс только в том, что мы осуществляем двухсторонюю аутентификацию на базе "самоподписанных" сертификатов Сервер присылает нам такой запрос Код: [2021-12-10 14:03:04] [FINE ] Received authorities list's size: 3 element(s) [2021-12-10 14:03:04] [FINE ] * CertificateRequest Cert Types: Type-22, Type-238, Type-239 Supported Signature Algorithms: GOST3411_2012_256withGOST3410_2012_256, GOST3411_2012_512withGOST3410_2012_512, GOST3411withGOST3410EL Cert Authorities: <CN=Головной удостоверяющий центр, OID.1.2.643.3.131.1.1=#120C303037373130343734333735, OID.1.2.643.100.1=#120D31303437373032303236373031, O=Минкомсвязь России, STREET="125375 г. Москва, ул. Тверская, д. 7", L=Москва, ST=77 г. Москва, C=RU, EMAILADDRESS=dit@minsvyaz.ru> <CN=Минкомсвязь России, OID.1.2.643.3.131.1.1=#120C303037373130343734333735, OID.1.2.643.100.1=#120D31303437373032303236373031, O=Минкомсвязь России, STREET="улица Тверская, дом 7", L=г. Москва, ST=77 Москва, C=RU, EMAILADDRESS=dit@minsvyaz.ru> <CN=CryptoPro GOST Root CA, O="LLC \"Crypto-Pro\"", L=Moscow, ST=Moscow, C=RU, OID.1.2.643.3.131.1.1=#120C303037373137313037393931, OID.1.2.643.100.1=#120D31303337373030303835343434> [2021-12-10 14:03:04] [ALL ] [read] MD5 and SHA1 hashes: len = 818 Далее по логам Код: [2021-12-10 14:03:04] [FINE ] Certificate request received... [2021-12-10 14:03:04] [FINE ] Search for client containers with GOST algorithms... [2021-12-10 14:03:04] [FINE ] Search for client containers with any GOST algorithm... [2021-12-10 14:03:04] [FINE ] %% getting aliases for Client [2021-12-10 14:03:04] [FINE ] %% checking alias: te-77c99eb4-9c50-46d3-82e2-0d963967bbeb... [2021-12-10 14:03:04] [FINE ] %% check public key algorithm ignored. [2021-12-10 14:03:04] [FINE ] %% signature algorithm not found. [2021-12-10 14:03:04] [FINE ] %% check extended key usage of Client, size: 3... [2021-12-10 14:03:04] [FINE ] %% Extended key usage found and verified. [2021-12-10 14:03:04] [FINE ] %% check credential issuers... [2021-12-10 14:03:04] [WARNING] %% No alias is match [2021-12-10 14:03:04] [FINE ] Appropriate client aliases not found. [2021-12-10 14:03:04] [FINE ] Containers not found. [2021-12-10 14:03:04] [FINE ] No appropriate cert was found. [2021-12-10 14:03:04] [FINE ] * Certificate message *** [2021-12-10 14:03:04] [FINE ] Generate ephemeral key pair. [2021-12-10 14:03:04] [FINER ] Ephemeral algorithm: GOST3410DHEPH_2012_256 with public key parameters: GOST3410_2012_256 [2021-12-10 14:03:04] [FINER ] Ephemeral key generator: GOST3410DHEPH_2012_256, provider: JCSP Получается мы отбраковываем ключ и сертификат из нашего хранилища, и создаем временную эфемерную пару? А зачем? Разве эфемерный сертификат будет подписан авторизованными центрами? Есть ли способ заставить JTLS принудительно использовать ключ и сертификат из хранилища, даже если они выпущены не авторизованным для сервера центром?


Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

Евгений Афанасьев		#15 Оставлено : 10 декабря 2021 г. 15:17:54(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 704 раз в 665 постах		Цитата: [2021-12-10 14:03:04] [FINE ] %% check credential issuers... [2021-12-10 14:03:04] [WARNING] %% No alias is match Видимо, не подходит издатель при проверке по списку, присланному сервером. Возможно, ваша цепочка содержит промежуточный сертификат, но в ключевом контейнере te-77c99eb4-9c50-46d3-82e2-0d963967bbeb только один сертификат - сертификат подписи, он не будет принят, т.к. его издателя нет в числе присланных сервером (сервер присылает имена корневых сертификатов, а не промежуточных). Установите полную цепочку сертификатов клиента в te-77c99eb4-9c50-46d3-82e2-0d963967bbeb. Эфемерный ключ используется всегда по соображениям безопасности, подпись выполняется ключом выбранного ключевого контейнера. "Есть ли способ заставить JTLS принудительно использовать ключ и сертификат из хранилища, даже если они выпущены не авторизованным для сервера центром?" - только если сервер пришлет пустой список, далее клиент выберет любой сертификат и отправит его на сервер, где уже задачей сервера будет, принимать ли такой сертификат.
		Тех. поддержка База знаний Логирование JCP Логирование JTLS Тест JCP и сбор диаг. информации Скачать JCP, JCSP и JTLS Скачать Android CSP + SDK


Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

RSS Лента

Atom Лента

Пользователи, просматривающие эту тему
Guest

2 Страницы<12

Быстрый переход

Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.

Important Information: The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies. More Details Close