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

Уведомление

Icon
Error

2 Страницы12>
Опции
К последнему сообщению К первому непрочитанному
Offline Alex_LM  
#1 Оставлено : 21 мая 2018 г. 10:39:39(UTC)
Alex_LM

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

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

Добрый день!

При разработке приложения столкнулись с проблемой: при установлении соединения с сервером по протоколу ГОСТ TLS 2001 возникает исключение: “PKIX path building failed: ru.CryptoPro.reprov.certpath.JCPCertPathBuilderException: unable to find valid certification path to requested target”. Есть подозрение, что ошибка связана с наличием в цепочке сертификатов сертификата RSA (серверный сертификат – ГОСТ, промежуточный и корневой - RSA), так как при наличии в цепочки только ГОСТ сертификатов соединение устанавливается нормально.
Ошибка проявляется на версиях JCP и JTLS 2.0. На версиях JTLS 1.0 ошибка не воспроизводится.

Трассировка стека тестового приложения:
Exception in thread "main" javax.net.ssl.SSLHandshakeException: ru.CryptoPro.ssl.pc_4.cl_5: PKIX path building failed: ru.CryptoPro.reprov.certpath.JCPCertPathBuilderException: unable to find valid certification path to requested target
at ru.CryptoPro.ssl.cl_2.a(Unknown Source)
at ru.CryptoPro.ssl.cl_97.a(Unknown Source)
at ru.CryptoPro.ssl.cl_58.a(Unknown Source)
at ru.CryptoPro.ssl.cl_58.a(Unknown Source)
at ru.CryptoPro.ssl.cl_15.a(Unknown Source)
at ru.CryptoPro.ssl.cl_15.a(Unknown Source)
at ru.CryptoPro.ssl.cl_58.u(Unknown Source)
at ru.CryptoPro.ssl.cl_58.a(Unknown Source)
at ru.CryptoPro.ssl.cl_97.a(Unknown Source)
at ru.CryptoPro.ssl.cl_97.n(Unknown Source)
at ru.CryptoPro.ssl.cl_97.b(Unknown Source)
at ru.CryptoPro.ssl.cl_97.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
at Proga.connect(Proga.java:125)
at Proga.main(Proga.java:50)
Caused by: ru.CryptoPro.ssl.pc_4.cl_5: PKIX path building failed: ru.CryptoPro.reprov.certpath.JCPCertPathBuilderException: unable to find valid certification path to requested target
at ru.CryptoPro.ssl.pc_4.cl_2.a(Unknown Source)
at ru.CryptoPro.ssl.pc_4.cl_2.a(Unknown Source)
at ru.CryptoPro.ssl.pc_4.cl_4.b(Unknown Source)
at ru.CryptoPro.ssl.cl_125.a(Unknown Source)
at ru.CryptoPro.ssl.cl_125.a(Unknown Source)
at ru.CryptoPro.ssl.cl_125.checkServerTrusted(Unknown Source)
... 13 more

Подскажите пожалуйста, в чем может быть причина?
Поддерживает ли JTLS 2.0 использование такого сценария (использование в цепочке сертификатов одновременно ГОСТ и RSA).
Offline Евгений Афанасьев  
#2 Оставлено : 21 мая 2018 г. 12:00:42(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 688 раз в 649 постах
Здравствуйте.
JCP и JTLS не поддерживают работу с зарубежными алгоритмами, только ГОСТ (2001, 2012).
Offline Alex_LM  
#3 Оставлено : 21 мая 2018 г. 13:41:33(UTC)
Alex_LM

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

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

Спасибо большое за ответ.

Мы используем как раз алгоритмы ГОСТ 2001. Соответственно на сервере есть ключ подписи ГОСТ и соответствующий ГОСТ сертификат. В логах JTLS есть следующая запись:

<message>*** ServerHello, TLSv1
RandomCookie: GMT: -1766987953 bytes = { 103, 255, 106, 71, 88, 170, 64, 205, 210, 51, 162, 82, 59, 171, 96, 135, 2, 158, 46, 124, 94, 152, 108, 9, 16, 112, 118, 48 }
Session ID: {131, 130, 177, 6, 251, 140, 131, 116, 180, 22, 53, 119, 138, 140, 26, 169, 9, 238, 214, 6, 160, 40, 171, 249, 138, 119, 69, 46, 120, 14, 86, 50}
Cipher Suite: TLS_CIPHER_2001
Compression Method: 0
Extension server_name, server_name:
Extension renegotiation_info, renegotiated_connection: &lt;empty&gt;
Extension ext_hash_and_mac_alg_select, ext_hash_and_mac_alg_select: [48, 30, 48, 8, 6, 6, 42, -123, 3, 2, 2, 9, 48, 8, 6, 6, 42, -123, 3, 2, 2, 22, 48, 8, 6, 6, 42, -123, 3, 2, 2, 23]
***
</message>

и соответствующая запись ClientHello с перечнем CIPHERs - Cipher Suites: [TLS_CIPHER_2012, TLS_CIPHER_2001, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]

Однако, промежуточный и корневой сертификаты серверного ГОСТ сертификата - RSA. Насколько я понимаю, с концептуальной точки зрения эти сертификаты (промежуточный и корневой) не обязаны быть ГОСТ, они в данном случае нужны для подтверждения подлинности сертификата сервера (если это не так для JTLS, поправьте меня пожалуйста).

В процессе установки соединения сервер присылает цепочку сертификатов, которые есть в хранилище доверенных сертификатов на клиенте.
Мне не понятно, почему происходит ошибка построения цепочки сертификатов?
Обязаны ли все сертификаты в цепочке вплоть до корневого быть ГОСТ?
Как понять, какой именно сертификат он не смог найти при построения цепочки? Есть ли способ узнать причины, что именно "не понравилось"?
Offline Евгений Афанасьев  
#4 Оставлено : 21 мая 2018 г. 13:53:38(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 688 раз в 649 постах
В JTLS строится цепочка сертификатов и проверяются подписи сертификатов (поддерживаются только ГОСТ алгоритмы подписи).
Все сертификаты должны быть ГОСТ, т.к. иностранные алгоритмы просто не поддерживаются.
Попробуйте включить логирование, как описано тут - https://support.cryptopr...st/Index/6/kriptopro-jcp (Включение логов для JCP и JTLS).
Offline Alex_LM  
#5 Оставлено : 23 мая 2018 г. 13:59:10(UTC)
Alex_LM

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

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

Цитата:
Все сертификаты должны быть ГОСТ, т.к. иностранные алгоритмы просто не поддерживаются.


Есть ли явное указание этого ограничения в документации по JCP/JTLS? В документации по JCP я не нашел такого ограничения использования сертификатов, встречающиеся упоминания ссылаются на X.509, например: Программное обеспечение СКЗИ позволяет использовать российские криптографические алгоритмы и сертификаты открытых ключей стандарта X.509... Если действительно есть такое ограничение, то хотелось бы увидеть их в требованиях/ограничениях в документации.
Меня в данном случае смущает то, что
1. Предыдущая версия JCP у нас работала в данном сценарии.
2. Панель управления(ControlPanel) JCP строит таки цепочку сертификата с использованием проблемного хранилища.
3. При использовании реализации из пакета com.sun.net.ssl так же все работает. Я имею ввиду использование
import com.sun.net.ssl.SSLContext;
import com.sun.net.ssl.TrustManagerFactory;
вместо
import javax.net.ssl.SSLContext;
import javax.net.ssl.TrustManagerFactory;


Цитата:
Попробуйте включить логирование, как описано тут - https://support.cryptopr...st/Index/6/kriptopro-jcp (Включение логов для JCP и JTLS)

В первом сообщении я как раз привел кусок из логов, которое настраивал по этой инструкции. Собственно, по логам там не совсем понятно что происходит, там после того, как сервер присылает цепочку сертификатов идут записи:

<record>
<date>2018-05-23T17:30:50</date>
<millis>1527071450028</millis>
<sequence>147</sequence>
<logger>ru.CryptoPro.ssl.SSLLogger</logger>
<level>FINER</level>
<class>ru.CryptoPro.ssl.pc_4.cl_2</class>
<method>a</method>
<thread>1</thread>
<message>Signature provider: JCP</message>
</record>
<record>
<date>2018-05-23T17:30:50</date>
<millis>1527071450044</millis>
<sequence>190</sequence>
<logger>ru.CryptoPro.ssl.SSLLogger</logger>
<level>FINE</level>
<class>ru.CryptoPro.ssl.cl_96</class>
<method>invalidate</method>
<thread>1</thread>
<message>%% Invalidated: [Session-1, TLS_CIPHER_2001]</message>
</record>
<record>
<date>2018-05-23T17:30:50</date>
<millis>1527071450044</millis>
<sequence>191</sequence>
<logger>ru.CryptoPro.ssl.SSLLogger</logger>
<level>FINE</level>
<class>ru.CryptoPro.ssl.cl_97</class>
<method>a</method>
<thread>1</thread>
<message>main, SEND TLSv1 ALERT: fatal, </message>
</record>
<record>
<date>2018-05-23T17:30:50</date>
<millis>1527071450045</millis>
<sequence>192</sequence>
<logger>ru.CryptoPro.ssl.SSLLogger</logger>
<level>FINE</level>
<class>ru.CryptoPro.ssl.cl_97</class>
<method>a</method>
<thread>1</thread>
<message>description = certificate_unknown</message>
</record>
<record>
<date>2018-05-23T17:30:50</date>
<millis>1527071450045</millis>
<sequence>193</sequence>
<logger>ru.CryptoPro.ssl.SSLLogger</logger>
<level>ALL</level>
<class>ru.CryptoPro.ssl.cl_75</class>
<method>a</method>
<thread>1</thread>
<message>[Raw write]: length = 7
0000: 15 03 01 00 02 02 2E .......
</message>
</record>
<record>
<date>2018-05-23T17:30:50</date>
<millis>1527071450045</millis>
<sequence>194</sequence>
<logger>ru.CryptoPro.ssl.SSLLogger</logger>
<level>FINER</level>
<class>ru.CryptoPro.ssl.cl_97</class>
<method>h</method>
<thread>1</thread>
<message>main, called closeSocket()</message>
</record>
<record>
<date>2018-05-23T17:30:50</date>
<millis>1527071450045</millis>
<sequence>195</sequence>
<logger>ru.CryptoPro.ssl.SSLLogger</logger>
<level>WARNING</level>
<class>ru.CryptoPro.ssl.cl_97</class>
<method>a</method>
<thread>1</thread>
<message>main, handling exception: javax.net.ssl.SSLHandshakeException: ru.CryptoPro.ssl.pc_4.cl_5: PKIX path building failed: ru.CryptoPro.reprov.certpath.JCPCertPathBuilderException: unable to find valid certification path to requested target</message>
</record>

Как узнать причину появления данной ошибки?
В чем может быть причина того, что при использовании реализации классов com.sun.net.ssl.SSLContext и com.sun.net.ssl.TrustManagerFactory все работает, а при использовании javax.net.ssl.SSLContext и javax.net.ssl.TrustManagerFactory нет?
Почему, раз говорите, цепочка сертификатов должны быть полностью состоять из ГОСТ сертификатов, панель управления позволяет построить цепочку сертификатов, в которой есть сертификаты RSA?
Offline Евгений Афанасьев  
#6 Оставлено : 23 мая 2018 г. 15:12:28(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 688 раз в 649 постах
По поводу
Автор: Alex_LM Перейти к цитате
com.sun.net.ssl.SSLContext и com.sun.net.ssl.TrustManagerFactory все работает, а при использовании javax.net.ssl.SSLContext и javax.net.ssl.TrustManagerFactory

sun, естественно, поддерживает зарубежные алгоритмы. А так как при установке JTLS меняет настройки TrustManagerFactory и KeyManagerFactory в java.security, то это может влиять.
А на счет того, что не может построиться такая цепочка
Автор: Alex_LM Перейти к цитате
Почему, раз говорите, цепочка сертификатов должны быть полностью состоять из ГОСТ сертификатов, панель управления позволяет построить цепочку сертификатов, в которой есть сертификаты RSA?

мог обмануть. Не могли бы вы приложить цепочку сертификатов, которая не проверяется? Посмотрю (в jtls 2.0 построение цепочки и ее проверка изменились).

Отредактировано пользователем 23 мая 2018 г. 15:14:59(UTC)  | Причина: Не указана

Offline Alex_LM  
#7 Оставлено : 24 мая 2018 г. 6:34:47(UTC)
Alex_LM

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

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

Спасибо большое. Прикладываю цепочку. chain.7z (4kb) загружен 2 раз(а). Пароль пришлю в личном сообщении.
Offline Евгений Афанасьев  
#8 Оставлено : 24 мая 2018 г. 14:55:58(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 688 раз в 649 постах
Спасибо за информацию, ошибку воспроизвели. Действительно, проблема, видимо, в том, что провайдер подписи четко зафиксирован, поэтому подпись не-ГОСТ сертификатов не может быть проверена. Устраним ошибку в следующем релизе.
Offline Alex_LM  
#9 Оставлено : 25 мая 2018 г. 7:24:59(UTC)
Alex_LM

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

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

Спасибо большое!

Скажите, как скоро можно ожидать версию с исправлением?
Offline Евгений Афанасьев  
#10 Оставлено : 25 мая 2018 г. 15:33:02(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 688 раз в 649 постах
Ориентировочно в июле, но мы можем выслать вам сборку в начале следующей недели, напишите адрес email сюда или в личные сообщения.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest
2 Страницы12>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.