Редактировать: - Попытался отформатировать вопрос и принял ответ более презентабельным способом в моем блоге

Вот оригинальная проблема.

Я получаю эту ошибку:

подробное сообщение sun.security.validator.ValidatorException: сбой построения пути PKIX:
sun.security.provider.certpath.SunCertPathBuilderException: невозможно найти действительный путь сертификации к запрошенной цели

причиной javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: сбой построения пути PKIX: sun.security.provider.certpath.SunCertPathBuilderException: невозможно найти действительный путь сертификации к запрошенной цели

Я использую Tomcat 6 в качестве веб-сервера. У меня есть два веб-приложения HTTPS, установленные на разных Tomcats на разных портах, но на одной машине. Скажи App1(port 8443)и App2(port 443). App1подключается к App2. При App1подключении App2я получаю вышеуказанную ошибку. Я знаю, что это очень распространенная ошибка, поэтому сталкивался со многими решениями на разных форумах и сайтах. У меня есть ниже запись в server.xmlобоих Tomcats:

keystoreFile="c:/.keystore" 
keystorePass="changeit"

На каждом сайте указана одна и та же причина, по которой сертификат, предоставленный app2, отсутствует в доверенном хранилище app1 jvm. Кажется, это также верно, когда я пытался перейти по тому же URL-адресу в браузере IE, он работает (с потеплением. Существует проблема с сертификатом безопасности этого веб-сайта. Здесь я говорю, перейдите на этот веб-сайт). Но когда Java-клиент использует тот же URL-адрес (в моем случае), я получаю вышеуказанную ошибку. Поэтому, чтобы положить его в доверенное хранилище, я попробовал эти три варианта:

Опция 1

System.setProperty("javax.net.ssl.trustStore", "C:/.keystore");
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

Option2 Настройка ниже в переменной среды

CATALINA_OPTS -- param name
-Djavax.net.ssl.trustStore=C:\.keystore -Djavax.net.ssl.trustStorePassword=changeit ---param value

Option3 Настройка ниже в переменной среды

JAVA_OPTS -- param name
-Djavax.net.ssl.trustStore=C:\.keystore -Djavax.net.ssl.trustStorePassword=changeit ---param value

Но ничего не сработало .

Наконец, сработало выполнение подхода Java, предложенного в разделе Как обрабатывать недействительные сертификаты SSL с помощью Apache HttpClient? по Паскалю Thivent, т.е. выполнение программы InstallCert.

Но этот подход хорош для установки devbox, но я не могу использовать его в производственной среде.

Я задаюсь вопрос, почему три упомянутых выше подходы не сделали работу , когда я упомянул то же значение server.xmlиз app2сервера и те же значения в настройке с помощью доверенных сертификатов

System.setProperty("javax.net.ssl.trustStore", "C:/.keystore") and System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

в app1программе.

Для получения дополнительной информации вот как я делаю соединение:

URL url = new URL(urlStr);

URLConnection conn = url.openConnection();

if (conn instanceof HttpsURLConnection) {

  HttpsURLConnection conn1 = (HttpsURLConnection) url.openConnection();

  conn1.setHostnameVerifier(new HostnameVerifier() {
    public boolean verify(String hostname, SSLSession session) {
      return true;
    }
  });

  reply.load(conn1.getInputStream());

Вам необходимо добавить сертификат для App2 в файл хранилища доверенных сертификатов используемой JVM, расположенный по адресу %JAVA_HOME%\lib\security\cacerts.

Сначала вы можете проверить, находится ли ваш сертификат в хранилище доверенных сертификатов, выполнив следующую команду: keytool -list -keystore "%JAVA_HOME%/jre/lib/security/cacerts"(вам не нужно указывать пароль)

Если ваш сертификат отсутствует, вы можете получить его, загрузив его с помощью браузера и добавив его в склад доверенных сертификатов с помощью следующей команды:

keytool -import -noprompt -trustcacerts -alias <AliasName> -file <certificate> -keystore <KeystoreFile> -storepass <Password>

После импорта вы можете снова запустить первую команду, чтобы проверить, был ли добавлен ваш сертификат.

Информацию о Sun / Oracle можно найти здесь .

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: сбой построения пути PKIX: sun.security.provider.certpath.SunCertPathBuilderException: невозможно найти действительный путь сертификации для запрошенной цели

• Когда я получил сообщение об ошибке, я попытался выяснить значение выражения в Google и обнаружил, что эта проблема возникает, когда сервер меняет свой сертификат HTTPS SSL, а наша старая версия Java не распознает корневой центр сертификации (ЦС). ,

• Если вы можете получить доступ к URL-адресу HTTPS в своем браузере, то можно обновить Java для распознавания корневого ЦС.

• В браузере перейдите по URL-адресу HTTPS, к которому у Java нет доступа. Нажмите на цепочку сертификатов HTTPS (в Internet Explorer есть значок блокировки), нажмите на замок, чтобы просмотреть сертификат.

• Перейдите в «Детали» сертификата и «Копировать в файл». Скопируйте его в формате Base64 (.cer) . Он будет сохранен на вашем рабочем столе.

• Установите сертификат, игнорируя все предупреждения.

• Так я собрал информацию о сертификате URL-адреса, к которому я пытался получить доступ.

Теперь я должен был сделать свою версию Java известной о сертификате, чтобы в дальнейшем он не отказывался распознавать URL. В связи с этим я должен упомянуть, что, по-моему, информация о корневом сертификате по умолчанию остается в папке JDK \ jre \ lib \ security , а пароль по умолчанию для доступа: changeit.

Для просмотра информации о каскадах необходимо выполнить следующие процедуры:

• Нажмите кнопку Пуск -> Выполнить

• Введите cmd. Откроется командная строка (может потребоваться открыть ее как администратор).

• Перейдите в свой Java/jreX/binкаталог

• Введите следующее

keytool -list -keystore D: \ Java \ jdk1.5.0_12 \ jre \ lib \ security \ cacerts

Это дает список текущих сертификатов, содержащихся в хранилище ключей. Это выглядит примерно так:

C: \ Documents and Settings \ NeelanjanaG> список ключей -list -keystore D: \ Java \ jdk1.5.0_12 \ jre \ lib \ security \ cacerts

Введите пароль хранилища ключей: changeit

Тип хранилища ключей: JKS

Поставщик Keystore: SUN

Ваше хранилище ключей содержит 44 записи

verisignclass3g2ca, 26 марта 2004 г., trustCertEntry,

Отпечаток сертификата (MD5): A2: 33: 9B: 4C: 74: 78: 73: D4: 6C: E7: C1: F3: 8D: CB: 5C: E9

entrustclientca, 9 января 2003 г., trustCertEntry,

Отпечаток сертификата (MD5): 0C: 41: 2F: 13: 5B: A0: 54: F5: 96: 66: 2D: 7E: CD: 0E: 03: F4

thawtepersonalbasicca, 13 февраля 1999 г., trustCertEntry,

Отпечаток сертификата (MD5): E6: 0B: D2: C9: CA: 2D: 88: DB: 1A: 71: 0E: 4B: 78: EB: 02: 41

addtrustclass1ca, 1 мая 2006 г., trustCertEntry,

Отпечаток сертификата (MD5): 1E: 42: 95: 02: 33: 92: 6B: B9: 5F: C0: 7F: DA: D6: B2: 4B: FC

verisignclass2g3ca, 26 марта 2004 г., trustCertEntry,

Отпечаток сертификата (MD5): F8: BE: C4: 63: 22: C9: A8: 46: 74: 8B: B8: 1D: 1E: 4A: 2B: F6

• Теперь я должен был включить ранее установленный сертификат в cacerts.

• Для этого используется следующая процедура:

keytool –import –noprompt –trustcacerts –alias ALIASNAME -file FILENAME_OF_THE_INSTALLED_CERTIFICATE -keystore PATH_TO_CACERTS_FILE -storepass ПАРОЛЬ

Если вы используете Java 7:

keytool –importcert –trustcacerts –alias ALIASNAME -file PATH_TO_FILENAME_OF_THE_INSTALLED_CERTIFICATE -keystore PATH_TO_CACERTS_FILE -storepass changeit

• Затем он добавит информацию о сертификате в файл cacert.

Это решение, которое я нашел для исключения, упомянутого выше!

Как работает-это в Tomcat 7

Я хотел поддержать самозаверяющий сертификат в приложении Tomcat, но следующий фрагмент не работал

import java.io.DataOutputStream;
import java.net.HttpURLConnection;
import java.net.URL;

public class HTTPSPlayground {
    public static void main(String[] args) throws Exception {

        URL url = new URL("https:// ... .com");
        HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();

        httpURLConnection.setRequestMethod("POST");
        httpURLConnection.setRequestProperty("Accept-Language", "en-US,en;q=0.5");
        httpURLConnection.setDoOutput(true);
        DataOutputStream wr = new DataOutputStream(httpURLConnection.getOutputStream());

        String serializedMessage = "{}";
        wr.writeBytes(serializedMessage);
        wr.flush();
        wr.close();

        int responseCode = httpURLConnection.getResponseCode();
        System.out.println(responseCode);
    }
}

вот что решило мою проблему:

1) Скачать .crtфайл

echo -n | openssl s_client -connect <your domain>:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ~/<your domain>.crt

• заменить <your domain>на свой домен (например jossef.com)

2) Примените .crtфайл в cacertsхранилище сертификатов Java

keytool -import -v -trustcacerts -alias <your domain> -file ~/<your domain>.crt -keystore <JAVA HOME>/jre/lib/security/cacerts -keypass changeit -storepass changeit

• заменить <your domain>на свой домен (например jossef.com)
• заменить <JAVA HOME>на ваш домашний каталог Java

3) Взломать это

Хотя iv'e установил мой сертификат в хранилище сертификатов по Javaумолчанию, Tomcat игнорирует это (похоже, он не настроен на использование хранилищ сертификатов по умолчанию в Java).

Чтобы взломать это, добавьте в ваш код следующее:

String certificatesTrustStorePath = "<JAVA HOME>/jre/lib/security/cacerts";
System.setProperty("javax.net.ssl.trustStore", certificatesTrustStorePath);

// ...

В моем случае проблема заключалась в том, что веб-сервер отправлял только сертификат и промежуточный ЦС, а не корневой ЦС. Добавление этой опции JVM решило проблему:-Dcom.sun.security.enableAIAcaIssuers=true

Доступна поддержка метода доступа caIssuers расширения Authority Information Access. По умолчанию он отключен для совместимости и может быть включен, установив системное свойство com.sun.security.enableAIAcaIssuersв значение true.

Если установлено значение true, реализация Sun для PKIX CertPathBuilder использует информацию в расширении AIA сертификата (в дополнение к указанному CertStores), чтобы найти сертификат выдающего CA, при условии, что это URI типа ldap, http или ftp.

Источник

Еще одной причиной может быть устаревшая версия JDK. Я использовал jdk версии 1.8.0_60, просто обновление до последней версии решило проблему с сертификатом.

Мой файл cacerts был полностью пуст. Я решил эту проблему, скопировав файл cacerts с моего компьютера с Windows (который использует Oracle Java 7) и скопировал его на мою Linux-коробку (OpenJDK).

cd %JAVA_HOME%/jre/lib/security/
scp cacerts mylinuxmachin:/tmp

а затем на машине Linux

cp /tmp/cacerts /etc/ssl/certs/java/cacerts

Пока все отлично работает.

Для меня эта ошибка также возникла при попытке подключиться к процессу за обратным прокси-сервером NGINX, который обрабатывал SSL.

Оказалось, что проблема заключалась в сертификате без объединения всей цепочки сертификатов. Когда я добавил промежуточные сертификаты, проблема была решена.

Надеюсь это поможет.

Используя Tomcat 7 под Linux, это помогло.

String certificatesTrustStorePath = "/etc/alternatives/jre/lib/security/cacerts";
System.setProperty("javax.net.ssl.trustStore", certificatesTrustStorePath);
System.setProperty("javax.net.ssl.trustStorePassword", "changeit");

Под Linux $JAVA_HOMEне всегда настраивается, но обычно /etc/alternatives/jreуказывает на$JAVA_HOME/jre

Ниже код работает для меня:

import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;

import javax.net.ssl.X509TrustManager;

public class TrustAnyTrustManager implements X509TrustManager {

public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
}

public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
}

public X509Certificate[] getAcceptedIssuers() {
return new X509Certificate[] {};
}
}

HttpsURLConnection conn = null;
            URL url = new URL(serviceUrl);
            conn = (HttpsURLConnection) url.openConnection();
             SSLContext sc = SSLContext.getInstance("SSL");  
             sc.init(null, new TrustManager[]{new TrustAnyTrustManager()}, new java.security.SecureRandom());  

             conn.setSSLSocketFactory(sc.getSocketFactory());

Я использовал, jdk1.8.0_171когда столкнулся с той же проблемой. Я попробовал два лучших решения здесь (добавление сертификата с помощью keytool и другого решения, в котором есть хак), но они не сработали для меня.

Я обновил свой JDK до, 1.8.0_181и он работал как шарм.

Я написал небольшой сценарий Win32 (WinXP 32bit Testet) глупый cmd (командной строки), который ищет все версии Java в программных файлах и добавляет к ним сертификат. Пароль должен быть «changeit» по умолчанию или изменить его самостоятельно в скрипте :-)

@echo off

for /F  %%d in ('dir /B %ProgramFiles%\java') do (
    %ProgramFiles%\Java\%%d\bin\keytool.exe -import -noprompt -trustcacerts -file some-exported-cert-saved-as.crt -keystore %ProgramFiles%\Java\%%d\lib\security\cacerts -storepass changeit
)

pause

Для MacOS X ниже точная команда работала для меня, где я должен был попробовать с двойным hypen в опции importcert, которая работала:

sudo keytool -–importcert -file /PathTo/YourCertFileDownloadedFromBrowserLockIcon.crt -keystore /Library/Java/JavaVirtualMachines/jdk1.8.0_191.jdk/Contents/Home/jre/lib/security/cacerts -alias "Cert" -storepass changeit

Для меня не сработало признанное решение из этого поста: https://stackoverflow.com/a/9619478/4507034 .

Вместо этого мне удалось решить проблему, импортировав сертификацию в сертификацию моей машины.

шаги:

1. Перейдите по URL (например https://localhost:8443/yourpath), где сертификация не работает.
2. Экспортируйте сертификацию, как описано в упомянутом посте.
3. На вашем компьютере Windows откройте: Manage computer certificates
4. Перейти к Trusted Root Certification Authorities->Certificates
5. Импортируйте сюда свой your_certification_name.cerфайл.

Чтобы Tomcat работал на сервере Ubuntu, чтобы узнать, какая Java используется, используйте команду «ps -ef | grep tomcat»:

Образец:

/home/mcp01$ **ps -ef |grep tomcat**
tomcat7  28477     1  0 10:59 ?        00:00:18 **/usr/local/java/jdk1.7.0_15/bin/java** -Djava.util.logging.config.file=/var/lib/tomcat7/conf/logging.properties -Djava.awt.headless=true -Xmx512m -XX:+UseConcMarkSweepGC -Djava.net.preferIPv4Stack=true -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar -Dcatalina.base=/var/lib/tomcat7 -Dcatalina.home=/usr/share/tomcat7 -Djava.io.tmpdir=/tmp/tomcat7-tomcat7-tmp org.apache.catalina.startup.Bootstrap start
1005     28567 28131  0 11:34 pts/1    00:00:00 grep --color=auto tomcat

Затем мы можем перейти по адресу : cd /usr/local/java/jdk1.7.0_15/jre/lib/security

Файл cacerts по умолчанию находится здесь. Вставьте в него ненадежный сертификат.

для безопасности мы не должны использовать самозаверяющие сертификаты в нашей реализации. Тем не менее, когда речь заходит о разработке, нам часто приходится использовать пробные среды с самоподписанными сертификатами. Я попытался исправить эту проблему программно в моем коде, и мне это не удалось. Однако добавление сертификата в jre trust-store решило мою проблему. Пожалуйста, найдите ниже шаги,

1. Скачать сайт сертификата,

   • Использование Chrome
   • Использование Firefox

2. Скопируйте сертификат (например, cert_file.cer) в каталог $ JAVA_HOME \ Jre \ Lib \ Security

3. Откройте CMD в Администраторе и измените каталог на $ JAVA_HOME \ Jre \ Lib \ Security

4. Импортируйте сертификат в доверенное хранилище, используя следующую команду:

keytool -import -alias ca -file cert_file.cer -keystore cacerts -storepass changeit

Если вы получили сообщение о том, что keytool не распознается, обратитесь к этому.

Тип да как ниже

Доверяйте этому сертификату: [Да]

5. Теперь попробуйте запустить свой код или получить доступ к URL программно с помощью Java.

Обновить

Если ваш сервер приложений jboss, попробуйте добавить системное свойство ниже

System.setProperty("org.jboss.security.ignoreHttpsHost","true");

Надеюсь это поможет!

ДЕПОЛОГИЧЕСКОЕ РЕШЕНИЕ (Alpine Linux)

Чтобы исправить эту проблему в наших прикладных средах, мы подготовили команды терминала Linux следующим образом:

cd ~

Сгенерирует файл сертификата в домашнем каталоге.

apk add openssl

Эта команда устанавливает openssl в Alpine Linux. Вы можете найти подходящие команды для других дистрибутивов Linux.

openssl s_client -connect <host-dns-ssl-belongs> < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > public.crt

Сгенерировал нужный файл сертификата.

sudo $JAVA_HOME/bin/keytool -import -alias server_name -keystore $JAVA_HOME/lib/security/cacerts -file public.crt -storepass changeit -noprompt

Применяет сгенерированный файл к JRE с помощью программы 'keytool'.

Примечание: пожалуйста, замените ваш DNS на<host-dns-ssl-belongs>

Примечание 2: пожалуйста, обратите внимание, что -nopromptне будет запрашивать подтверждение (да / нет) и-storepass changeit параметр отключит запрос пароля и предоставит необходимый пароль (по умолчанию «changeit»). Эти два свойства позволят вам использовать эти сценарии в ваших прикладных средах, таких как создание образа Docker.

Примечание3 Если вы развертываете свое приложение через Docker, вы можете сгенерировать секретный файл один раз и поместить его в файлы проекта приложения. Вам не нужно будет генерировать это снова и снова.

У меня тоже есть эта проблема.

Я попробовал почти все, добавив сертификат SSL в .keystore, но он не работал с Java1_6_x. Для меня это помогло, если бы мы начали использовать более новую версию Java, Java1_8_x в качестве JVM.

У меня была эта проблема с Android Studio, когда я за прокси. Я использовал Crashlytics, который пытается загрузить файл сопоставления во время сборки.

Я добавил недостающий сертификат прокси в склад доверенных сертификатов, расположенный по адресу /Users/[username]/Documents/Android Studio.app/Contents/jre/jdk/Contents/Home/jre/lib/security/cacerts

с помощью следующей команды: keytool -import -trustcacerts -keystore cacerts -storepass [password] -noprompt -alias [alias] -file [my_certificate_location]

например, с паролем хранилища доверенных сертификатов по умолчанию keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias myproxycert -file /Users/myname/Downloads/MyProxy.crt

Просто небольшой взлом. Обновите URL-адрес в файле "hudson.model.UpdateCenter.xml" с https на http

<?xml version='1.1' encoding='UTF-8'?>
<sites>
  <site>
    <id>default</id>
    <url>http://updates.jenkins.io/update-center.json</url>
  </site>
</sites>

Я хочу присоединиться, так как у меня есть среда QEMU, где я должен загружать файлы в Java. Оказывается, /etc/ssl/certs/java/cacertsв QEMU действительно есть проблема, потому что она не соответствует/etc/ssl/certs/java/cacerts среде хоста. Хост-среда находится за прокси-сервером компании, поэтому java cacerts является настроенной версией.

Если вы используете среду QEMU, убедитесь, что хост-система может сначала получить доступ к файлам. Например, вы можете сначала попробовать этот скрипт на вашем хост-компьютере, чтобы увидеть. Если скрипт отлично работает на хост-машине, но не в QEMU, то у вас та же проблема, что и у меня.

Чтобы решить эту проблему, мне пришлось сделать резервную копию исходного файла в QEMU, скопировать файл в среде хоста в изолированную тюрьму QEMU, а затем java мог нормально загружать файлы в QEMU.

Лучшим решением было бы монтировать /etcв среду QEMU; однако я не уверен, будут ли затронуты другие файлы в этом процессе. Поэтому я решил использовать этот уродливый, но легкий обходной путь.

Это кажется хорошим местом для документирования другой возможной причины печально известного сообщения об ошибке PKIX. Потратив слишком много времени на просмотр содержимого хранилища ключей и доверенных сертификатов и различных конфигураций установки Java, я понял, что моя проблема сводится к ... опечатке.

Опечатка означала, что я также использовал хранилище ключей в качестве хранилища доверенных сертификатов. Поскольку мои компании Root CA не был определен как отдельный сертификат в хранилище ключей, а только как часть цепочки сертификатов, и не был определен где-либо еще (например, cacerts), я продолжал получать ошибку PKIX.

После неудачного релиза (это prod config, все было хорошо в другом месте) и двух дней царапин на голове, я наконец увидел опечатку, и теперь все хорошо.

Надеюсь, это кому-нибудь поможет.

добавьте это в свой код:

TrustManager[] trustAllCerts = new TrustManager[]{
           new X509TrustManager() {
               @Override
               public java.security.cert.X509Certificate[] getAcceptedIssuers() {
                   return new X509Certificate[0];
               }

               @Override
               public void checkClientTrusted(
                       java.security.cert.X509Certificate[] certs, String authType) {
               }

               @Override
               public void checkServerTrusted(
                       java.security.cert.X509Certificate[] certs, String authType) {
               }
           }
       };

       try {
           SSLContext sc = SSLContext.getInstance("SSL");
           sc.init(null, trustAllCerts, new java.security.SecureRandom());
           HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
       } catch (GeneralSecurityException e) {
       }