Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 704 раз в 665 постах
|
При таком детальном логировании пишутся все ошибки, даже не существенные, конкретно на эту можно не обращать внимание. Сервер доверяет определённым издателям, их список он предварительно шлет клиенту Цитата: 2024-04-17 15:00:43.011 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] *** 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: <EMAILADDRESS=e-notary@signal-com.ru, CN=УЦ e-Notary (ГОСТ Р 34.10-2012), OU=Удостоверяющий центр, O="АО \"СИГНАЛ-КОМ\"", L=Москва, C=RU>
Тут только один издатель. В логе сервер запросил сертификат клиента, клиентский сертификат найден, но не был отправлен, тк не прошёл проверку по имени издателя, видимо, найденный в контейнере сертификат издан не CN=УЦ e-Notary (ГОСТ Р 34.10-2012): Цитата: 2024-04-17 15:00:43.013 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] %% checking alias: 5f4338b6-4171-401c-85c5-97a5a3f028b6... 2024-04-17 15:00:43.013 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] %% certificate chain length = 1 2024-04-17 15:00:43.013 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] %% check credential issuers... 2024-04-17 15:00:43.013 WARN 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] %% No alias is match 2024-04-17 15:00:43.013 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] Containers not found. 2024-04-17 15:00:43.013 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] No appropriate cert was found. 2024-04-17 15:00:43.014 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] *** Certificate message ***
Частая причина ошибки тут: в ключевой контейнер клиента установлен только один сертификат ключа, нужно установить всю цепочку сертификатов клиента. Отредактировано пользователем 17 апреля 2024 г. 22:29:10(UTC)
| Причина: Не указана |
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 16.04.2024(UTC) Сообщений: 11 Сказал(а) «Спасибо»: 1 раз
|
Автор: Евгений Афанасьев При таком детальном логировании пишутся все ошибки, даже не существенные, конкретно на эту можно не обращать внимание. Сервер доверяет определённым издателям, их список он предварительно шлет клиенту Цитата: 2024-04-17 15:00:43.011 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] *** 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: <EMAILADDRESS=e-notary@signal-com.ru, CN=УЦ e-Notary (ГОСТ Р 34.10-2012), OU=Удостоверяющий центр, O="АО \"СИГНАЛ-КОМ\"", L=Москва, C=RU>
Тут только один издатель. В логе сервер запросил сертификат клиента, клиентский сертификат найден, но не был отправлен, тк не прошёл проверку по имени издателя, видимо, найденный в контейнере сертификат издан не CN=УЦ e-Notary (ГОСТ Р 34.10-2012): Цитата: 2024-04-17 15:00:43.013 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] %% checking alias: 5f4338b6-4171-401c-85c5-97a5a3f028b6... 2024-04-17 15:00:43.013 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] %% certificate chain length = 1 2024-04-17 15:00:43.013 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] %% check credential issuers... 2024-04-17 15:00:43.013 WARN 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] %% No alias is match 2024-04-17 15:00:43.013 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] Containers not found. 2024-04-17 15:00:43.013 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] No appropriate cert was found. 2024-04-17 15:00:43.014 DEBUG 89012 --- [qtp716216643-90] ru.CryptoPro.ssl.SSLLogger : [] *** Certificate message ***
Частая причина ошибки тут: в ключевой контейнер клиента установлен только один сертификат ключа, нужно установить всю цепочку сертификатов клиента. Я правильно понимаю что под ключевым контейнером понимается папки с файлами .key? (там где пара закрытый ключ и сертификат) В java ещё настраивается так Цитата: HDImageStore.setDir(sbCryptoProperties.getPrivateContainer().getPath()); final KeyManagerFactory kmf = KeyManagerFactory.getInstance(Provider.KEYMANGER_ALG, Provider.PROVIDER_NAME); final KeyStore keyStore = KeyStore.getInstance(JCP.HD_STORE_NAME); keyStore.load(null, null); kmf.init(keyStore, null);
Если да, то так и есть, в контейнере находится один сертификат без полной цепочки. У меня в контейнере trust store лежит вся цепочка, я потом попробовал сделать так: 1. Зашёл в хранилище контейнеров -> HDImageStore -> <выбрал нужный контейнер> 2. Нажал кнопку построить, выбрал из хранилища сертификатов нужный контейнер 3. Он мне построил всю цепочку 4. Сохранил в формате p7b А вот что делать дальше, не пойму. Пример как получилось Screenshot.png (30kb) загружен 8 раз(а).
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 704 раз в 665 постах
|
"Я правильно понимаю что под ключевым контейнером понимается папки с файлами .key?" - да. "У меня в контейнере trust store лежит вся цепочка" - то, что лежит в trust store, имеет отношение к серверу, не к клиенту, и используется для построения и проверки серверной цепочки. Клиентская цепочка берется только из контейнера. Вся цепочка клиента (в формате p7b) должна быть установлена в клиентский контейнер и строится в таком виде она будет без "выбрал из хранилища сертификатов". Если у вас есть p7b с полной цепочкой клиента, то раскройте узел контейнера клиента, выберите справа "Добавить сертификат", добавьте в контейнер p7b. Далее при раскрытии узла контейнера будут видны 3 сертификата, а не один. Отредактировано пользователем 18 апреля 2024 г. 16:09:32(UTC)
| Причина: Не указана |
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 16.04.2024(UTC) Сообщений: 11 Сказал(а) «Спасибо»: 1 раз
|
Автор: Евгений Афанасьев "Я правильно понимаю что под ключевым контейнером понимается папки с файлами .key?" - да. "У меня в контейнере trust store лежит вся цепочка" - то, что лежит в trust store, имеет отношение к серверу, не к клиенту, и используется для построения и проверки серверной цепочки. Клиентская цепочка берется только из контейнера. Вся цепочка клиента (в формате p7b) должна быть установлена в клиентский сертификат и строится в таком виде она будет без "выбрал из хранилища сертификатов". Если у вас есть p7b с полной цепочкой клиента, то раскройте узел контейнера клиента, выберите справа "Добавить сертификат", добавьте в контейнер p7b. Далее при раскрытии узла контейнера будут видны 3 сертификата, а не один. Ещё раз огромное спасибо. Всё получилось, теперь получаю корректные ответы на запросы. Сделал как вы сказали, файл в формате p7b (там цепочка сертификатов) добавил в ключевой контейнер, теперь там полный набор. Сейчас более понятен стал механизм взаимодействия при помощи сертификатов крипто про 1. Есть понимание на что конкретно смотреть в логах, в случае подобных проблем (какие сертификаты запрашивает сервер, что при этом клиент отвечает) 2. Наличие полной цепочки сертификатов в ключевом контейнере (правда у нас есть ещё одна интеграция, где в ключевом контейнере лежит только один сертификат, без полной цепочки и подобных ошибок при этом нет)
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 704 раз в 665 постах
|
Для п.2 есть еще альтернатива, она выглядит примерно так: Код:
// множество промежуточных сертификатов
Set<X509Certificate> certs = new HashSet<>();
certs.add(...);
// общее хранилище с корневыми сертификатами для построения цепочки сертификатов не только сервера, но и клиентской стороны
KeyStore trustStore = KeyStore.getInstance(...);
trustStoreForClient.load(...);
List<CertStore> certStores = new ArrayList<>(1);
certStores.add(CertStore.getInstance("Collection", new CollectionCertStoreParameters(certs)));
PKIXBuilderParameters parameters = new PKIXBuilderParameters(trustStore, new X509CertSelector());
parameters.setRevocationEnabled(false); // можно отключить проверку цепочки клиента
parameters.setCertStores(certStores);
TrustManagerFactory tmf = TrustManagerFactory.getInstance(...);
tmf.init(trustStore); // trustStore для построения цепочки сервера
// ключевой контейнер в случае клиентской аутентификации
KeyStore keyStore = KeyStore.getInstance(...);
keyStore.load(...);
// параметры для построения цепочки клиента перед установлением соединения
JavaTLSCertPathManagerParameters managerParameters = new JavaTLSCertPathManagerParameters(keyStore, keyPassword);
managerParameters.setParameters(parameters);
KeyManagerFactory kmf = KeyManagerFactory.getInstance(...);
kmf.init(managerParameters); // может бросить исключение
SSLContext sslContext = SSLContext.getInstance(...);
sslContext.init(sslConfig.kmf.getKeyManagers(), sslConfig.tmf.getTrustManagers(), null);
Будет произведена попытка построить цепочку клиента из keyStore с помощью certs и trustStore. То есть в этом случае в keyStore в ключевом контейнере клиента может быть один сертификат, но его цепочка может быть достроена (если получится) с помощью certs и trustStore. Если цепочка не будет достроена, то отправится все тот же один сертификат. Другой вариант: использовать метод JavaTLSCertPathManagerParameters#tlsClientDisableIssuerCheck(), чтобы принудительно отправить сертификат клиента, не проверяя его издателя. Это работает, если в KeyStore с клиентским контейнером передали алиас конкретного контейнера: Код:
KeyStore keyStore = KeyStore.getInstance(...);
keyStore.load(new StoreInputStream(keyAlias), null);
Если на сервере есть промежуточный сертификат, то он построит и проверит клиентскую цепочку, хотя клиент отправил только один сертификат. Отредактировано пользователем 18 апреля 2024 г. 16:35:22(UTC)
| Причина: Не указана |
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 16.04.2024(UTC) Сообщений: 11 Сказал(а) «Спасибо»: 1 раз
|
Автор: Евгений Афанасьев Здравствуйте.
Ошибка "SunCertPathBuilderException: unable to find valid certification path to requested target" возникает, когда не удается построить цепочку сертификатов другой стороны (например, на клиенте при построении цепочки сервера). Причины могут быть разные: истек срок сертификата, цепочка неполная и т.п.
По поводу "SSLHandshakeException: Server sent the extended_master_secret extension improperly" - обновите сборку JCP, позднее были доработки. Здравствуйте. Не стал заводить новую тему, но столкнулся с проблемой после обновления JCP с версии 2.0.42188-A на версию 2.0.45042-A, а именно, отваливаются запросы по keep-alive, я нашёл тему на этом форуме https://cryptopro.ru/for...aspx?g=posts&t=21701 проблема ровно такая же как в теме по ссылке, после нескольких удачных запросов начинают отбивать ошибки вида 403.7 (Forbidden: Client certificate required), но стоило только вернуться на версию 2.0.42188-A ошибки исчезли! Подскажите, как бороться с проблемой в версии 2.0.45042-A? Иначе оказался в такой ситуации когда для новой интеграции требуется версия 2.0.45042-A, но при этом отваливается из-за ошибок связанных с keep-alive старая интеграция. Отредактировано пользователем 27 июня 2024 г. 23:49:32(UTC)
| Причина: Не указана
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,963 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 704 раз в 665 постах
|
Здравствуйте. Указанная ошибка возникнет, если клиент не отправил расширение EMS (отправка отключена или криптонабор не поддерживает EMS), но получил его от сервера. Если есть возможность, включите логи SSLLogger уровня ALL, как тут, https://support.cryptopr...lirovnija-kriptopro-jtls , и приложите лог. Затем попробуйте запустить с ru.CryptoPro.ssl.useExtendedMasterSecret=false, например, так: Код:
java -Dru.CryptoPro.ssl.useExtendedMasterSecret=false ...
или в коде в самом начале: Код:
System.setProperty("ru.CryptoPro.ssl.useExtendedMasterSecret", "false");
И проверить так. Клиент совсем не будет отправлять EMS. Отредактировано пользователем 28 июня 2024 г. 11:29:54(UTC)
| Причина: Не указана |
|
|
|
|
Статус: Участник
Группы: Участники
Зарегистрирован: 16.04.2024(UTC) Сообщений: 11 Сказал(а) «Спасибо»: 1 раз
|
Автор: Евгений Афанасьев Здравствуйте. Указанная ошибка возникнет, если клиент не отправил расширение EMS (отправка отключена или криптонабор не поддерживает EMS), но получил его от сервера. Если есть возможность, включите логи SSLLogger уровня ALL, как тут,, приложите лог. Затем попробуйте запустить с ru.CryptoPro.ssl.useExtendedMasterSecret=false, например, так: Код:
java -Dru.CryptoPro.ssl.useExtendedMasterSecret=false ...
или в коде в самом начале: Код:
System.setProperty("ru.CryptoPro.ssl.useExtendedMasterSecret", "false");
И проверить так. Клиент совсем не будет отправлять EMS. Спасибо, попробую предложенный вами вариант
|
|
|
|
Статус: Новичок
Группы: Участники
Зарегистрирован: 09.09.2024(UTC) Сообщений: 1
|
Здравствуйте! Помогите пожалуйста, возникла аналогичная ошибка 403.7 при обращении к парнёру. Причем проявляется не всегда, а только в (предположительно) периоды продолжающейся наибольшей нагрузки, и также бесследно проходит после. В ходе анализа трассировки запроса заметил в логах, что иногда (приложил 3 трейса, и во 2ом этой ошибки не было) выскакивает ошибка ru.CryptoPro.ssl.SSLLogger qtp1103666479-25, handling exception: java.net.SocketTimeoutException: Read timed outно сам процесс запроса на этом не стопается, идёт дальше процесс подписания и потом отваливается с вышеуказанной ошибкой. Других подозрительный логов не наблюдаю, уровень логирования был выкручен в trace. okb-403.7-error-trace-1.txt (22kb) загружен 5 раз(а). okb-403.7-error-trace-2.txt (22kb) загружен 2 раз(а). okb-403.7-error-trace-3.txt (23kb) загружен 2 раз(а).Используем в проекте Spring Boot, группу библиотек ru.CryptoPro версии 2.0.42188-AПротокол - GostTLSv1.2 Http client - org.apache.http.impl.client.CloseableHttpClient Конфигурация SSLContext Код:
KeyStore trustStore = KeyStore.getInstance(JCP.HD_STORE_NAME, JCP.PROVIDER_NAME);
trustStore.load(new FileInputStream(okbCryptoProperties.getTrustStore().getPath()), okbCryptoProperties.getTrustStore().getPassword().toCharArray());
TrustManagerFactory tmf = TrustManagerFactory.getInstance(Provider.KEYMANGER_ALG, Provider.PROVIDER_NAME);
tmf.init(trustStore);
HDImageStore.setDir(okbCryptoProperties.getPrivateContainer().getPath());
KeyManagerFactory kmf = KeyManagerFactory.getInstance(Provider.KEYMANGER_ALG, Provider.PROVIDER_NAME);
KeyStore keyStore = KeyStore.getInstance(JCP.HD_STORE_NAME);
keyStore.load(null, null);
kmf.init(keyStore, null);
SSLContext context = SSLContext.getInstance(Provider.ALGORITHM_12); // протокол GostTLSv1.2 - TLS v.1.2, GostTLSv1.1, GostTLS
context.init(kmf.getKeyManagers(), tmf.getTrustManagers(), SecureRandom.getInstance("CPRandom", JCP.PROVIDER_NAME));
Также прикладываю сравнительный график за 1 конкретно-взятый период, в ходе которого сервис не перезагружался, и его конфигурация "на лету" так же не менялась. Sravnitel'nyjj grafik.png (101kb) загружен 10 раз(а).По нему можно заметить динамику прохождения успешных и неуспешных запросов. Вышепредложенное решение с `ru.CryptoPro.ssl.useExtendedMasterSecret=false`, к сожалению, не дало результата.
|
|
|
|
Статус: Сотрудник
Группы: Модератор, Участники Зарегистрирован: 03.12.2018(UTC) Сообщений: 1,193 Сказал(а) «Спасибо»: 100 раз Поблагодарили: 274 раз в 254 постах
|
Добрый день.
с актуальной версией воспроизводится? |
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close