Разрешение javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: сбой построения пути PKIX Ошибка?

426

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

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

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

подробное сообщение 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());
М Сач
источник
возможный дубликат HttpClient и SSL
маркиз Лорн
Как ни странно, я получил эту ошибку при обмене данными между кластерными серверами, у которых не было проблем с SSL по отдельности. Как только я правильно установил domainnameсвои серверы RHEL, проблема исчезла. Надеюсь, это кому-нибудь поможет.
DavidG
Еще одна вещь, которую нужно проверить, это то, что у вас установлена ​​последняя версия Java - из-за этого я получил похожую ошибку.
Redzarf
stackoverflow.com/questions/2893819/… - тоже актуальный и фантастический ответ.
Сиддхартха

Ответы:

406

Вам необходимо добавить сертификат для 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 можно найти здесь .

SimonSez
источник
6
Вам придется использовать полный путь, например, c: \ java \ jdk \ lib \ security \ cacerts
SimonSez
48
Как сказал SimonSez, вам не нужен пароль, но если вы хотите, пароль по умолчанию «changeit».
Феликс
16
Кроме того, в Windows вам необходимо запустить терминал от имени администратора, в противном случае вы получите сообщение об ошибке keytool error: java.io.FileNotFoundException ... (Access is denied)при попытке импортировать сертификат.
Феликс
2
Ах, @SimonSez, ты мой бог. Но чтобы добавить к нему, нужно указать расположение хранилища доверенных сертификатов и пароль, указанные @M Sach, чтобы заставить его работать.
BudsNanKis
2
Продолжали возникать проблемы с Java 1.8. Необходимо добавить сертификат, как описано, и использовать Java <1.8
Том Ховард
180

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.

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

NDeveloper
источник
5
Что вы делаете, когда истекает срок действия сертификата? Повторить все (ежегодно)?
ggkmath
7
Есть ли способ сделать это программно?
Мешулам Шелк
1
Для людей, имеющих дело с ошибкой PKIX «Путь не связан ни с одним из якорей доверия», это решение, к сожалению, не решило эту проблему для меня.
IcedDante
3
Один вопрос - является ли aliasName веб-адресом, для которого мы импортируем сертификат? Например, если URL-адрес - domain.site.com/pages/service.asmx, тогда псевдоним должен быть domain.site.com или полный URL-адрес (domain.site.com/pages/service.asmx) или к нему также должен быть добавлен префикс http : // или это просто произвольное имя?
Нанософт
1
путь: \ lib \ security> keytool -import -noprompt -trustcacerts -alias webCert -file webCertResource.cer -keystore c: / Users / Jackie / Desktop -storepass changeit Я получаю "система не может найти указанный файл"
Джесси
46

Как работает-это в 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);

// ...
Йосеф Харуш
источник
4
Шаг 2 помог мне, используя SpringBoot и Tomcat 7. Спасибо.
Тим Перри
Нужно ли мне использовать keytool из java, который используется tomcat? Потому что на одном сервере у меня может быть много java
vikifor
@ Викифор да. Вы также можете запустить его для всех java-каталогов, установленных в вашей системе
Jossef Harush
1
Это сработало! большое спасибо @JossefHarush за такой полезный ответ!
Том Тейлор
1
моя проблема была решена после добавления сегмента кода @Jossef Harush в мой код.
Чамод Патирана
10

В моем случае проблема заключалась в том, что веб-сервер отправлял только сертификат и промежуточный ЦС, а не корневой ЦС. Добавление этой опции 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.

Источник

Гийом
источник
Это фактически решило мою проблему, спасибо!
Луис Сильва
6

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

Али Исмайлов
источник
2
У меня тоже была такая же проблема. Вызов API с сертификатом Lets Encrypt может не работать со старыми версиями Java, поскольку он не распознается доверенными корневыми центрами сертификации. Обновление Java решит эту проблему.
Hertg
5

Мой файл 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

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

Райан Шиллингтон
источник
1
Это прекрасно работает, если проблема в том, что вы используете более старую версию Java, которая не имеет последних сертификатов.
atripathi
@atripathi как насчет Mac?
iOSAndroidWindowsMobileAppsDev
Что-то серьезно не так с вашей установкой Java, если файл cacerts был пуст. Вы должны были переустановить все это.
маркиз Лорн
Возможно, но это решение сработало, и потом ничего не было неправильно.
Райан Шиллингтон
5

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

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

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

Яда
источник
это похоже на то, что у меня есть. Можете ли вы объяснить, как вы добавили промежуточные сертификаты и где. Я использую httpd реверс прокси, а не NGINX.
Асаф Маген
Это помогло мне в моем случае, потому что я использую httpd: access.redhat.com/solutions/43575
Асаф Маген,
С nginx он использует только файлы .key и .pem для конфигурации SSL. Сначала вы конвертируете .crt в .pem (просто: cp yourfile.crt yourfile.pem), а затем для цепочки сертификатов SSL: добавляете файл .cer к последнему из .pem (cat yourfile.cer >> yourfile.pem)
Thế Anh Nguyễn
5

Используя 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

Седрик Саймон
источник
5

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

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());
Сандип С.
источник
5
Этот код абсолютно небезопасен и не должен использоваться.
маркиз Лорн
@ user207421 Почему это небезопасно? Что происходит в коде вкратце.
Говинда Сахаре
Это пропускает все проверки сертификатов, в основном это позволяет принимать любой сертификат. Способ работы сертификатов заключается в том, что корневой сертификат (буквально) физически защищен в различных органах сертификации. Этот сертификат затем используется для выдачи других вторичных сертификатов, которые могут быть проверены вплоть до корневого центра сертификации. Это пропускает все исходящие проверки, что означает, что я могу отправить любой ssl-сертификат (даже самостоятельно созданный), и ваше приложение примет его как безопасный, даже если моя идентификационная информация в качестве URL-адреса не подтверждена.
Скотт Тейлор
4

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

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

AVP
источник
2

Я написал небольшой сценарий 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
монс дроид
источник
2

Для 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
Абхишек
источник
2

Для меня не сработало признанное решение из этого поста: 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файл.
Раду Лину
источник
1

Чтобы 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 по умолчанию находится здесь. Вставьте в него ненадежный сертификат.

oraclesoon
источник
1

для безопасности мы не должны использовать самозаверяющие сертификаты в нашей реализации. Тем не менее, когда речь заходит о разработке, нам часто приходится использовать пробные среды с самоподписанными сертификатами. Я попытался исправить эту проблему программно в моем коде, и мне это не удалось. Однако добавление сертификата в 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 не распознается, обратитесь к этому.

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

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

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

Обновить

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

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

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

tk_
источник
1

ДЕПОЛОГИЧЕСКОЕ РЕШЕНИЕ (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, вы можете сгенерировать секретный файл один раз и поместить его в файлы проекта приложения. Вам не нужно будет генерировать это снова и снова.

Бахадир Тасдемир
источник
0

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

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

нубийский
источник
1
Мне то же. Обновление с Java 1.8.0_91 до 1.8.0_121 решило проблему. Я получил исключение при использовании Apache HTTPClient.
Devabc
У меня все еще есть проблема с использованием аутентификации Oauth2
Sofiane
0

У меня была эта проблема с 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

Wirling
источник
0

Просто небольшой взлом. Обновите 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>
Harshavardhan
источник
0

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

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

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

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

рок
источник
0

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

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

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

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

Дейв Ричардсон
источник
-1

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

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) {
       }

источник
1
Ответы только на код обычно не одобряются на этом сайте. Не могли бы вы отредактировать свой ответ, включив в него некоторые комментарии или пояснения к коду? Объяснения должны отвечать на такие вопросы, как: Что это делает? Как это сделать? Куда это идет? Как это решает проблему ОП?
mypetlion
1
добавьте в свой код No. Не добавляйте это в код . Создание SSLContext таким способом удаляет все проверки безопасности, которые проверяют подлинность сервера, к которому вы подключаетесь. Ответом на проблему потери ваших ключей НЕ является удаление всех замков из всего, что у вас есть.
Эндрю Хенле