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

Уведомление

Icon
Error

3 Страницы<123>
Опции
К последнему сообщению К первому непрочитанному
Offline Евгений Афанасьев  
#11 Оставлено : 17 апреля 2024 г. 17:32:13(UTC)
Евгений Афанасьев

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

Группы: Участники
Зарегистрирован: 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)  | Причина: Не указана

Offline mrResident  
#12 Оставлено : 18 апреля 2024 г. 10:08:45(UTC)
mrResident

Статус: Участник

Группы: Участники
Зарегистрирован: 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 раз(а).
Offline Евгений Афанасьев  
#13 Оставлено : 18 апреля 2024 г. 11:04:20(UTC)
Евгений Афанасьев

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

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

Сказал(а) «Спасибо»: 20 раз
Поблагодарили: 704 раз в 665 постах
"Я правильно понимаю что под ключевым контейнером понимается папки с файлами .key?" - да.
"У меня в контейнере trust store лежит вся цепочка" - то, что лежит в trust store, имеет отношение к серверу, не к клиенту, и используется для построения и проверки серверной цепочки. Клиентская цепочка берется только из контейнера. Вся цепочка клиента (в формате p7b) должна быть установлена в клиентский контейнер и строится в таком виде она будет без "выбрал из хранилища сертификатов". Если у вас есть p7b с полной цепочкой клиента, то раскройте узел контейнера клиента, выберите справа "Добавить сертификат", добавьте в контейнер p7b. Далее при раскрытии узла контейнера будут видны 3 сертификата, а не один.

Отредактировано пользователем 18 апреля 2024 г. 16:09:32(UTC)  | Причина: Не указана

Offline mrResident  
#14 Оставлено : 18 апреля 2024 г. 11:39:39(UTC)
mrResident

Статус: Участник

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

Сказал(а) «Спасибо»: 1 раз
Автор: Евгений Афанасьев Перейти к цитате
"Я правильно понимаю что под ключевым контейнером понимается папки с файлами .key?" - да.
"У меня в контейнере trust store лежит вся цепочка" - то, что лежит в trust store, имеет отношение к серверу, не к клиенту, и используется для построения и проверки серверной цепочки. Клиентская цепочка берется только из контейнера. Вся цепочка клиента (в формате p7b) должна быть установлена в клиентский сертификат и строится в таком виде она будет без "выбрал из хранилища сертификатов". Если у вас есть p7b с полной цепочкой клиента, то раскройте узел контейнера клиента, выберите справа "Добавить сертификат", добавьте в контейнер p7b. Далее при раскрытии узла контейнера будут видны 3 сертификата, а не один.


Ещё раз огромное спасибо. Всё получилось, теперь получаю корректные ответы на запросы. Сделал как вы сказали, файл в формате p7b (там цепочка сертификатов) добавил в ключевой контейнер, теперь там полный набор.

Сейчас более понятен стал механизм взаимодействия при помощи сертификатов крипто про

1. Есть понимание на что конкретно смотреть в логах, в случае подобных проблем (какие сертификаты запрашивает сервер, что при этом клиент отвечает)
2. Наличие полной цепочки сертификатов в ключевом контейнере (правда у нас есть ещё одна интеграция, где в ключевом контейнере лежит только один сертификат, без полной цепочки и подобных ошибок при этом нет)
Offline Евгений Афанасьев  
#15 Оставлено : 18 апреля 2024 г. 16:28:06(UTC)
Евгений Афанасьев

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

Группы: Участники
Зарегистрирован: 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)  | Причина: Не указана

Offline mrResident  
#16 Оставлено : 27 июня 2024 г. 23:48:31(UTC)
mrResident

Статус: Участник

Группы: Участники
Зарегистрирован: 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)  | Причина: Не указана

Offline Евгений Афанасьев  
#17 Оставлено : 28 июня 2024 г. 11:02:22(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)  | Причина: Не указана

Offline mrResident  
#18 Оставлено : 28 июня 2024 г. 11:27:06(UTC)
mrResident

Статус: Участник

Группы: Участники
Зарегистрирован: 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.


Спасибо, попробую предложенный вами вариант
Offline Петров Павел  
#19 Оставлено : 18 сентября 2024 г. 17:50:02(UTC)
Петров Павел

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

Группы: Участники
Зарегистрирован: 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`, к сожалению, не дало результата.
Offline Санчир Момолдаев  
#20 Оставлено : 24 сентября 2024 г. 23:10:42(UTC)
Санчир Момолдаев

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

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

Сказал(а) «Спасибо»: 100 раз
Поблагодарили: 274 раз в 254 постах
Добрый день.

с актуальной версией воспроизводится?
Техническую поддержку оказываем тут
Наша база знаний
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest
3 Страницы<123>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.