Прерывистая ошибка SSL: невозможно найти действительный путь сертификации к запрошенной цели

Question

Я работаю с HttpClient, вызывая службу отдыха через SSL - я использую eclipse в качестве IDE.
Я загрузил сертификат службы отдыха с помощью браузера и импортировал его в мое Java хранилище ключей в java \ jdk1. 8.0_144 \ jre \ lib \ security \ cacerts
Большую часть времени ecerything работает нормально, я могу получить ответ,
Но у меня возникает эта неустойчивая ошибка SSL: невозможно найти действительный путь сертификации к запрошенной цели

У меня есть теория, почему это происходит, но я не уверен, верна ли теория, и у меня есть некоторые вопросы
об этом.

1. это возможный сценарий? : Если на цели есть несколько узлов (под балансировщиком нагрузки) и у меня есть сертификат только для одного из узлов?
2. Прерывистая проблема с разрешениями, когда затмение не может прочитать хранилище ключей?
3. Возможно ли, что цель использует несколько сертификатов SSL, а у меня есть только один?
4. eclipse использует этот путь java \ jdk1.8.0_144 \
   Я добавил сертификат в java \ jdk1.8.0_144 \ jre \ lib \ security \ cacerts
   do мне нужно добавить его в \ java \ jdk1.8.0_144 \ lib \ security ?

Если у вас есть какой-либо вклад, я буду рад получить любой вклад.

Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
    at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
    at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:392)
    ... 51 more

Answer 1

1. это возможный сценарий? : Если на цели есть несколько узлов (под балансировщиком нагрузки) и у меня есть сертификат только для одного из узлов?

Если балансировщик нагрузки находится на уровне TCP или IP, возможно. Это, безусловно, может позволить различным бэкэндам выполнять свое собственное завершение TLS, и хотя все бэкэнды для данного имени домена (или, в более общем случае, имени хоста) должны использовать одни и те же сертификаты, кто-то мог допустить ошибку. Если балансировщик нагрузки находится на уровне HTTP (приложения), он должен выполнить завершение TLS, чтобы обработать HTTP-запрос (включая файлы cookie и c), поэтому имеет значение только сертификат на балансировщике нагрузки.

Это также может происходить без явного балансировщика нагрузки. Некоторые системы выполняют неформальную балансировку на уровне IP, когда DNS разрешает свое имя по разным адресам в разное время - часто, но не обязательно, с помощью «циклического перебора» через фиксированный список. В результате, даже если вы отправляете на одно и то же имя, ваши соединения на самом деле go на разных, разных серверах. Другие - особенно CDN, такие как Cloudflare в настоящее время - используют «anycast», где имя преобразуется в постоянный адрес, но этот адрес может фактически go для разных физических серверов.

Подробнее см. Ниже.

Непостоянная проблема с разрешениями, когда Eclipse не может прочитать хранилище ключей?

Я сомневаюсь в этом. Во-первых, для ясности, когда вы запускаете программу Java в 'eclipse', eclipse фактически создает отдельную JVM для запуска указанной программы, опционально с отладкой и со стандартным вводом-выводом, настраиваемым, но по умолчанию в окне консоли eclipse. Это та JVM, которая должна прочитать truststore , который по умолчанию является файловым cacerts. (Java использует хранилище ключей files - и KeyStore class - для хранения нескольких видов ключевой информации, из которых сертификаты только один. Файл cacerts имеет формат jks, но содержит только доверенные сертификаты других сторон - именных ЦС, отсюда и название - и, следовательно, функционально является хранилищем доверенных сертификатов.)

Если возникла проблема при чтении кодеров, вы получите исключение, отличное от этого.

возможно ли, что цель использует несколько сертификатов SSL, а у меня только один?

Это, безусловно, возможно. Во-первых, если на самом деле есть несколько серверов, выполняющих завершение, как в # 1 выше, это может произойти по ошибке. Если на самом деле один сервер или устройство выполняет завершение:

• , если вы используете несколько имен хостов (доменных имен) в ваших URL, которые отображаются на один и тот же физический сервер, вполне возможно, что физический сервер использует разные сертификаты для разных «логических» серверов (например, «VirtualHost» в Apache)

• , если вы используете разные алгоритмы обмена ключами TLS для разных соединения, сервер может потребоваться (иметь и) использовать различные сертификаты. Например, если в некоторых соединениях используется обмен ключами ECDHE_RSA, а в некоторых - ECDHE_ECDSA, сервер должен использовать сертификат, содержащий ключ RSA для первого, и сертификат, содержащий ключ E CC для второго, и они должны отличаться. Но если в вашем коде не указаны подробности TLS, которые вы обычно не должны, или если вы устанавливаете свойства безопасности, чтобы отключить некоторые алгоритмы только для некоторых исполнений, клиент Java (JSSE) всегда будет предлагать одни и те же наборы шифров (и, следовательно, обмен ключами) и сервер последовательно получение этого же списка опций обычно всегда делает один и тот же выбор. (К вашему сведению: для TLS1.3 обмен ключами больше не контролируется ciphersuite, но 1.3 реализован только в j11 up, а не в j8.)

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

Я добавил сертификат в java \ jdk1.8.0_144 \ jre \ lib \ security \ cacerts. Нужно ли мне добавить его также в папку \ java \ jdk1.8.0_144 \ lib \ security?

Нет. JRE / lib / security / caerts - это правильное место. Как я уже говорил выше, ваш код фактически работает в JVM, которая использует только JRE, а не JDK в версиях, где они отличались, как это было в j8. (Более новые «модульные» версии Java больше не имеют фиксированного JRE; идея заключается в том, что вместо этого вы можете создавать специализированные JVM.)

Как часто происходит прерывистость? Если это происходит, скажем, один раз в час, а запросов в час всего несколько сотен, я бы включил javax.net.debug=ssl,handshake,trustmanager и перенаправил или перехватил стандартный вывод и посмотрел на него, чтобы увидеть, какие сертификаты действительно используются, когда и с какие результаты. OTOH, если это происходит один раз на миллиард запросов, проходящих через этот лог-файл, намного сложнее.