«Ошибка построения пути PKIX» при выполнении HTTP-запроса от Java

Question

Итак, вы столкнулись с легендарной проблемой PKIX Path Building. Это выглядит примерно так?

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed

Могу поспорить, так и есть. Я искренне надеюсь, что вы нашли этот ТАК вопрос, прежде чем часами расстроенно и бесполезно выискивать inte rnet способы спасения себя.

Давайте на высоком уровне go рассмотрим проблему, а затем копаться в конкретных растворах. (Credit Atlassian).

Отказ от ответственности для тех нетерпеливых людей, которые хотят пометить это как дубликат: есть много вопросов SO, связанных с построением пути PKIX, но все они бьют вокруг основной проблемы , Из личного опыта, связанного с этой проблемой (и тратящей много часов на ее решение), я знаю, как трудно отфильтровать шум. Я пишу этот вопрос, пытаясь просто и элегантно представить описание причины ошибки и ее наиболее быстрого устранения. Не стесняйтесь редактировать, чтобы добавить значимые детали, где это полезно.

Answer 1

Java Сертификаты

Всякий раз, когда Java пытается подключиться к другому приложению через TLS (SSL) (например, HTTPS, IMAPS, LDAPS), оно сможет подключиться только к этому приложение, если оно может доверять ему. В мире Java доверие обрабатывается так: у вас есть хранилище ключей (обычно $ JAVA_HOME / lib / security / cacerts), также известное как хранилище доверенных сертификатов. Он содержит список всех известных сертификатов центра сертификации (CA). Java будет доверять только сертификатам, которые подписаны одним из тех сертификатов CA * или , которые уже существуют в этом хранилище ключей.

Эта проблема возникает, если сервер представляет вам (клиент) сертификат, который является самоподписанным (ЦС не подписал его) или сертификат, который не существует в вашем доверенном хранилище Java. Java не доверяет сертификату и не может подключиться к приложению. Это заставляет вас чувствовать грусть и смотреть на ошибку PKIX path building failed.

Решение

В общем, решение этой проблемы заключается в получении публичного c сертификата хоста, которого вы ' Вы пытаетесь сделать запрос и добавить этот сертификат в свой TruStore. Звучит легко, правда? Это должно быть.

1. Получение сертификата

Вы можете получить сертификат c хоста, используя следующую команду: openssl s_client -connect <host>:<port>. Это должно вывести на консоль список сертификатов и прочую ерунду для данного хоста и порта. Что вы хотите сделать, это найти и скопировать строки из BEGIN CERTIFICATE в END CERTIFICATE. Кроме того, вы можете записать это содержимое непосредственно в файл, немного расширив команду: openssl s_client -connect <host>:<port> < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > public.crt. Содержимое public.crt должно выглядеть следующим образом:

-----BEGIN CERTIFICATE----- 
< Certificate content as fetched by the command line.  Don't change this
 content, only remove what is before  and after the BEGIN CERTIFICATE and
 END CERTIFICATE.  That's what your Sed command is doing for you :-) >
-----END CERTIFICATE-----  

2. Импортирование сертификата в ваше хранилище доверенных сертификатов

Вы захотите импортировать новое обнаруженное public.crt в хранилище доверенных сертификатов, которое используется, когда выполняется HTTP-запрос из любого места, где запущено ваше приложение java. Это может быть сделано с чем-то вроде <JAVA_HOME>/bin/keytool -import -alias <server_name> -keystore <path/to/truststore.jks> -file public.crt.

Вы можете добавить сертификат в cacerts, обычно где-то как здесь <JAVA_HOME>/jre/lib/security/cacerts, или непосредственно в сам truststore.jks (это то, что я делал недавно).

Однажды это сделано, вы (клиент) теперь доверяете сертификату, который будет представлен сервером, и вы сможете сделать свой http-запрос. Если вы все еще получаете сообщение об ошибке, наиболее вероятной причиной является то, что вы не добавляете сертификат в правильный склад доверенных сертификатов. См. этот пост SO , где обычно хранится склад доверенных сертификатов. ``

Слабое цитирование:

Atlassian