Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,006  Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
Автор: Алексей Кирковский  sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Не удается пост роить цепочку для некоего сертификата. Если цепочка не строится для сертификата, который приложен (в составе цепочки), то промежуточный (наравне с сертификатом подписи) вы подаете при подписи? Или хотя бы добавьте его в cacerts, чтобы он оттуда взялся. |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 27.11.2020(UTC)
Сообщений: 14
|
Автор: Евгений Афанасьев Автор: Алексей Кирковский sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Не удается пост роить цепочку для некоего сертификата. Если цепочка не строится для сертификата, который приложен (в составе цепочки), то промежуточный (наравне с сертификатом подписи) вы подаете при подписи? Или хотя бы добавьте его в cacerts, чтобы он оттуда взялся. Я добавил и Тестовый головной и Тестовый промежуточный в cacerts. В ключе есть вся цепочка (там выше код есть). Я проверил, что из PrivateKey считываются все 3 сертификата. Именно дальше построение ru.CryptoPro.AdES.certificate.CertificateChainBuilderImpl.build почему-то падает и не находит путь.
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,006 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
|
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 27.11.2020(UTC)
Сообщений: 14
|
Автор: Евгений Афанасьев Я вверху приложил info.zip. Там внутри файл messages (в конце перед стеком лог JCP). Или там чего-то не хватает ?
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,006 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
Добавьте еще -Djava.security.debug=certpath при запуске. |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 27.11.2020(UTC)
Сообщений: 14
|
Автор: Евгений Афанасьев Добавьте еще -Djava.security.debug=certpath при запуске. Добавил.  messages.zip (254kb) загружен 3 раз(а).
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,006 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
Цитата:
Dec 4 10:56:20 Test java: certpath: SunCertPathBuilder.depthFirstSearchForward(): validation failed: java.security.InvalidKeyException: Алгоритм ключа не соответствует алгоритму подписи.
Попробуйте не добавлять самостоятельно BC, без него, для теста. Выглядит так, что он может мешать (дает не тот алгоритм открытого ключа, который ожидает JCP). |
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 27.11.2020(UTC)
Сообщений: 14
|
Автор: Евгений Афанасьев Цитата:
Dec 4 10:56:20 Test java: certpath: SunCertPathBuilder.depthFirstSearchForward(): validation failed: java.security.InvalidKeyException: Алгоритм ключа не соответствует алгоритму подписи.
Попробуйте не добавлять самостоятельно BC, без него, для теста. Выглядит так, что он может мешать (дает не тот алгоритм открытого ключа, который ожидает JCP). Так я сам и не добавляю BC. В провайдеры его добавляет какая-то библиотека на старте. Ее не так легко вычислить (да и после того как вычислю, не очень понятно что потом делать). Тут более интересная проблема в том, что если я добавляю эти провайдеры в явную в java.security вот в таком порядке : Цитата:
security.provider.1=SUN
security.provider.2=SunRsaSign
security.provider.3=SunEC
security.provider.4=SunJSSE
security.provider.5=SunJCE
security.provider.6=SunJGSS
security.provider.7=SunSASL
security.provider.8=XMLDSig
security.provider.9=SunPCSC
security.provider.10=JdkLDAP
security.provider.11=JdkSASL
security.provider.12=SunPKCS11
security.provider.13=JCP
security.provider.14=RevCheck
security.provider.15=Crypto
security.provider.16=BC
То получаю вот такую ошибку при обращении, например к HttpClientBuilder. При этом подписание работает, зато перестает работать просто обращение по HTTPS к тому же ЧЗ. То есть похоже JCP подменяет то, что нужно для работы BC. Цитата:
Dec 4 12:37:34 Test java: FINE: [pool-11-System.interpreter-pausable-daemon-1] check URL: file:/usr/share/jcp-2.0.40450-A/JCP.jar
Dec 4 12:37:34 Test java: дек. 04, 2020 2:37:34 PM ru.CryptoPro.JCP.pref.JCPPref get
Dec 4 12:37:34 Test java: CONFIG: User Preference Node: /ru/CryptoPro/JCP/KeyStore/HDImage.HDImageStore_class_default=/var/opt/cprocsp/keys/${user.name}
Dec 4 12:37:34 Test java: дек. 04, 2020 2:37:34 PM ru.CryptoPro.JCP.KeyStore.JCPKeyStore engineLoad
Dec 4 12:37:34 Test java: FINER: RETURN
Dec 4 12:37:34 Test java: дек. 04, 2020 2:37:34 PM ru.CryptoPro.ssl.SSLContextImpl$DefaultSSLContext l
Dec 4 12:37:34 Test java: INFO: init keymanager of type GostX509
Dec 4 12:37:34 Test java: дек. 04, 2020 2:37:34 PM ru.CryptoPro.ssl.SSLContextImpl$DefaultSSLContext <init>
Dec 4 12:37:34 Test java: WARNING: default context init failed:
Dec 4 12:37:34 Test java: java.security.NoSuchAlgorithmException: GostX509 KeyManagerFactory not available
Dec 4 12:37:34 Test java: at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:159)
Dec 4 12:37:34 Test java: at java.base/javax.net.ssl.KeyManagerFactory.getInstance(KeyManagerFactory.java:148)
Dec 4 12:37:34 Test java: at ru.CryptoPro.ssl.SSLContextImpl$DefaultSSLContext.l(Unknown Source)
Dec 4 12:37:34 Test java: at ru.CryptoPro.ssl.SSLContextImpl$DefaultSSLContext.<init>(Unknown Source)
Dec 4 12:37:34 Test java: at ru.CryptoPro.ssl.SSLContextImpl$DefaultSSLContext.j(Unknown Source)
Dec 4 12:37:34 Test java: at ru.CryptoPro.ssl.SSLSocketFactoryImpl.<init>(Unknown Source)
Dec 4 12:37:34 Test java: at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
Dec 4 12:37:34 Test java: at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
Dec 4 12:37:34 Test java: at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
Dec 4 12:37:34 Test java: at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
Dec 4 12:37:34 Test java: at java.base/java.lang.Class.newInstance(Class.java:584)
Dec 4 12:37:34 Test java: at java.base/javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:110)
Dec 4 12:37:34 Test java: at org.apache.http.impl.client.HttpClientBuilder.build(HttpClientBuilder.java:973)
|
|
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 27.11.2020(UTC)
Сообщений: 14
|
Дальше - еще интереснее. Когда provider добавляется через код, то возникновение ошибки "Алгоритм ключа не соответствует алгоритму подписи" зависит от того, кто первый вызовется HttpClientBuilder, или проинициализируется JCP. Если через HttpClientBuilder хоть раз сделать запрос по HTTPS, то JCP больше не будет работать (по ошибке алгоритма подписи). Если проинициализировать провайдеры JCP раньше - то работает. Отредактировано пользователем 4 декабря 2020 г. 15:31:32(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 4,006 Откуда: Крипто-Про Сказал(а) «Спасибо»: 21 раз
Поблагодарили: 715 раз в 675 постах
|
Автор: Алексей Кирковский В провайдеры его добавляет какая-то библиотека на старте Скорее всего, она добавляет с помощью addProvider, в конец списка. Это нормально. Автор: Алексей Кирковский java.security.NoSuchAlgorithmException: GostX509 KeyManagerFactory not availabl Не увидел в коде или java.security, где вы добавляете JTLS (TLS провайдер), например, Security.addProvider(new Provider()); потому алгоритма GostX509 нет. Автор: Алексей Кирковский То есть похоже JCP подменяет то, что нужно для работы BC. Я писал выше, что и JCP, и BC реализуют работу с открытыми ГОСТ ключами. Тот провайдер, что выше в списке, и будет перехватывать и декодировать (если умеет) открытые ключи (по OID алгоритма), потому что java по умолчанию не использует имя провайдера (да и не знает) для четкого указания, кто должен декодировать незнакомый ей ключ (в сертификате). Использовать одновременно несколько провайдеров, одинаково реализующих работу с открытым ключом, нужно осторожно, так как провайдеры могут мешать друг другу. Автор: Алексей Кирковский возникновение ошибки "Алгоритм ключа не соответствует алгоритму подписи" зависит от того, кто первый вызовется HttpClientBuilder, или проинициализируется JCP. Это странно, разве что обращение к HttpClientBuilder перезагружает провайдеры, но из java.security они обычно загружаются в том порядке, как они там указаны (у них есть номера). Отредактировано пользователем 7 декабря 2020 г. 12:05:31(UTC)
| Причина: Не указана |
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
