Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

2 Страницы<12
Опции
К последнему сообщению К первому непрочитанному
Offline what_is_it@inbox.ru  
#11 Оставлено : 12 марта 2019 г. 11:38:24(UTC)
what_is_it@inbox.ru

Статус: Активный участник

Группы: Участники
Зарегистрирован: 27.02.2013(UTC)
Сообщений: 38
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 14 раз
Поблагодарили: 11 раз в 9 постах
Не совсем поняла Вас здесь:
Цитата:
Установите в контейнер всю цепочку вплоть до корневого (p7b)

Цепочку сертификатов в контейнер нужно установить на клиенте? Куда и как это правильно сделать, какой контейнер имеется ввиду?
Для отправки мы используем сертификат напрямую с ключевого носителя (инициализируем рутокен-store или OCFStore в зависимости от типа ключа)
У нас сейчас (на клиенте) вся цепочка установлена в корневые сертификаты локального компьютера (и в используемую клиентским приложением JRE)


Или все же речь идет о серверной части?
Нам коллеги, которые занимаются серверной частью пишут, что у них все установлено, ссылаясь на то, что авторизация через браузер работает. Но через браузер, как мне казалось,на клиенте смотрятся корневые сертификаты? Не подскажете ссылку на документацию, где об этом хорошо написано?

Отредактировано пользователем 12 марта 2019 г. 11:48:05(UTC)  | Причина: Не указана

Offline Евгений Афанасьев  
#12 Оставлено : 12 марта 2019 г. 14:10:09(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,910
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
Автор: 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 интерфейсе.

thanks 1 пользователь поблагодарил Евгений Афанасьев за этот пост.
what_is_it@inbox.ru оставлено 13.03.2019(UTC)
Offline what_is_it@inbox.ru  
#13 Оставлено : 13 марта 2019 г. 10:59:26(UTC)
what_is_it@inbox.ru

Статус: Активный участник

Группы: Участники
Зарегистрирован: 27.02.2013(UTC)
Сообщений: 38
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 14 раз
Поблагодарили: 11 раз в 9 постах
Разобрались. Проблема была в том, что на ключевом носителе была, видимо, неправильно установлена цепочка сертификатов.
Исправили так:
1. Экспортировали сертификат с контейнера на жесткий диск
2. С помощью мастера экспортировали сертификат вместе со всей цепочкой в файл p7b
3. Перезаписали через панель JCP эту цепочку обратно в контейнер

Отредактировано пользователем 13 марта 2019 г. 12:30:29(UTC)  | Причина: Не указана

Offline ShmakovAA  
#14 Оставлено : 10 декабря 2021 г. 13:15:45(UTC)
ShmakovAA

Статус: Новичок

Группы: Участники
Зарегистрирован: 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 принудительно использовать ключ и сертификат из хранилища, даже если они выпущены не авторизованным для сервера центром?
Offline Евгений Афанасьев  
#15 Оставлено : 10 декабря 2021 г. 15:17:54(UTC)
Евгений Афанасьев

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 06.12.2008(UTC)
Сообщений: 3,910
Российская Федерация
Откуда: Крипто-Про

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 685 раз в 646 постах
Цитата:

[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 принудительно использовать ключ и сертификат из хранилища, даже если они выпущены не авторизованным для сервера центром?" - только если сервер пришлет пустой список, далее клиент выберет любой сертификат и отправит его на сервер, где уже задачей сервера будет, принимать ли такой сертификат.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
2 Страницы<12
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.