Вирішення 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");

Варіант2 Налаштування нижче в змінній середовища

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

Варіант3 Налаштування нижче в змінній середовища

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

Але нічого не вийшло .

Що, нарешті, працювало, це виконувати підхід Java, запропонований у розділі Як поводитися з недійсними сертифікатами SSL за допомогою Apache HttpClient? Pascal 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 - через це я отримував подібну помилку.
Редзарф

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 можна знайти тут .


6
Вам доведеться використовувати повний шлях, наприклад c: \ java \ jdk \ lib \ security \ cacerts
SimonSez

48
Як сказав SimonSez, вам не потрібен пароль, але якщо ви цього хочете, пароль за замовчуванням - "changeit".
Фелікс

16
Також у Windows потрібно запустити термінал як адміністратор, інакше ви отримаєте помилку keytool error: java.io.FileNotFoundException ... (Access is denied)при спробі імпортувати свій сертифікат.
Фелікс

2
Ах @ СимонСез ти мій бог. Але щоб додати його, потрібно вказати місцезнаходження та пароль довіреного магазину, як згадував @M Sach, щоб він працював.
BudsNanKis

2
Продовжували виникати проблеми з Java 1.8. Потрібно додати cert, як описано, та використовувати Java <1,8
Том Говард

180

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

• Коли я отримав помилку, я спробував Google визначити значення виразу, і я виявив, що ця проблема виникає, коли сервер змінює свій сертифікат SSL HTTPS, а наша старіша версія Java не розпізнає авторитет кореневого сертифіката (CA) .

• Якщо ви можете отримати доступ до URL-адреси HTTPS у своєму браузері, тоді можна оновити Java для розпізнавання кореневого CA.

• У своєму браузері перейдіть до URL-адреси HTTPS, до якої Java не змогла отримати доступ. Клацніть на ланцюжку сертифікатів HTTPS (у Internet Explorer є значок блокування), натисніть на замок, щоб переглянути сертифікат.

• Перейдіть до "Деталі" сертифіката та "Копіювати у файл". Скопіюйте його у формат Base64 (.cer) . Він буде збережений на робочому столі.

• Встановіть сертифікат, ігноруючи всі сповіщення.

• Так я зібрав інформацію про сертифікат URL-адреси, до якої я намагався отримати доступ.

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

Для перегляду інформації про катетери, слід виконати наступні процедури:

• Натисніть кнопку Пуск -> Виконати

• Введіть cmd. Відкриється командний рядок (можливо, вам знадобиться відкрити його як адміністратор).

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

• Наберіть наступне

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

Він дає список поточних сертифікатів, що містяться в магазині ключів. Це виглядає приблизно так:

C: \ Документи та налаштування \ NeelanjanaG> список клавіш -list -keystore D: \ Java \ jdk1.5.0_12 \ jre \ lib \ security \ cacerts

Введіть пароль зберігання клавіш: changeit

Тип магазинного магазину: jks

Постачальник брелоків: SUN

У вашому магазині брелоків є 44 записи

verisignclass3g2ca, 26 березня 2004 року, trustedCertEntry,

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

entrustclientca, 9 січня 2003 року, trustedCertEntry,

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

thawtepersonalbasicca, 13 лютого 1999 року, довіренийCertEntry,

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

addtrustclass1ca, 1 травня 2006 року, trustedCertEntry,

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

verisignclass2g3ca, 26 березня 2004 року, trustedCertEntry,

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

• Тепер мені довелося включити раніше встановлений сертифікат до касетів.

• Для цього наступна процедура:

keytool –import –noprompt –trustcacerts –alias ALIASNAME -файл FILENAME_OF_THE_INSTALLED_CERTIFICATE -keystore PATH_TO_CACERTS_FILE -захід PASSWORD

Якщо ви використовуєте Java 7:

keytool –importcert –trustcacerts –alias ALIASNAME –файл PATH_TO_FILENAME_OF_THE_INSTALLED_CERTIFICATE –ключення магазину PATH_TO_CACERTS_FILE -затримка змінити

• Після цього буде додано інформацію про сертифікат у файл cacert.

Це рішення, яке я знайшов для виключення, згаданого вище !!


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 : // або це просто довільна назва?
nanosoft

1
path: \ lib \ security> keytool -import -noprompt -trustcacerts -alias webCert -file webCertResource.cer -keystore c: / Users / Jackie / Desktop -затримати зміниit Я отримую "система не може знайти вказаний файл"
Jesse

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

@vikifor так. Ви також можете запустити його для всіх java dirs, встановлених у вашій системі
Джозеф Харуш

1
Це спрацювало! дякую тоні @JossefHarush за таку корисну відповідь!
Том Тейлор

1
мою проблему було вирішено після додавання кодового сегмента @Jossef Harush у мій код.
Chamod Pathirana

10

У моєму випадку проблема полягала в тому, що веб-сервер надсилає лише сертифікат і проміжний CA, а не кореневий CA. Додавання цього параметра JVM вирішило проблему:-Dcom.sun.security.enableAIAcaIssuers=true

Доступна підтримка способу доступу касисурів до розширення доступу до інформації про орган. Він за умовчанням відключається для сумісності і може бути включений, встановивши для властивості системи com.sun.security.enableAIAcaIssuersзначення true.

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

Джерело


Це фактично вирішило мою проблему, дякую!
Luís Silva

6

Ще однією причиною може бути застаріла версія JDK. Я використовував jdk версії 1.8.0_60, просто оновивши останню версію, вирішив проблему з сертифікатом.


2
У мене була така ж проблема. Виклик API з сертифікатом Lets Encrypt може не працювати з більш старими версіями Java, оскільки він не розпізнається довіреними органами кореневої сертифікації. Оновлення Java вирішить цю проблему.
Герт

5

Файл моїх кекерів був абсолютно порожнім. Я вирішив це, скопіювавши файл 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 як щодо Mac?
iOSAndroidWindowsMobileAppsDev

У вашій установці Java щось серйозно не було, якщо файл cacerts був порожнім. Вам слід було це все перевстановити.
Маркіз Лорн

Можливо, але це рішення спрацювало, і після цього нічого ніколи не було.
Райан Шиллінгтон

5

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

Виявилося, що проблема полягала в сертифікаті без з’єднання цілого ланцюга. Коли я додав проміжні серти, проблема була вирішена.

Сподіваюсь, це допомагає.


це схоже на те, що у них є. Ви можете пояснити, як ви додали проміжні сертифікати та де. я використовую httpd revers проксі, а не NGINX.
Асаф Маген

це допомогло мені в моєму випадку, оскільки я використовую httpd: access.redhat.com/solutions/43575
Magen

За допомогою nginx він використовує лише файли .key та .pem для конфігурації SSL. Спочатку ви конвертуєте .crt в .pem (просто: cp yourfile.crt yourfile.pem), а потім для ланцюга cert SSL: ви додаєте файл .cer до останнього .pem (кішка yourfile.cer >> yourfile.pem)
Thh 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 Чому це небезпечно? Що відбувається в коді коротко.
Говінда Сахаре

Це пропускає всі перевірки сертифікатів, в основному це дозволяє прийняти будь-який сертифікат. Як працює certs, це те, що кореневий сертифікат (буквально) захищений фізично, в різних органах, що сертифікують. Потім цей сертифікат використовується для видачі інших вторинних сертифікатів, які можуть бути підтверджені назад до кореневого сертифікаційного органу. Це пропускає всі перевірки вгорі, це означає, що я можу надсилати будь-який ssl cert (навіть самостійно генерований), і ваша програма сприйме це як безпечне, навіть якщо моя особа як URL не підтверджена.
Скотт Тейлор

4

Я використовував, jdk1.8.0_171коли стикався з тією ж проблемою. Тут я спробував топ-2 рішення (додав сертифікат за допомогою keytool та інше рішення, в якому є хак), але вони не працювали для мене.

Я модернізував свій JDK до, 1.8.0_181і це спрацювало як шарм.


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 нижче - точна команда, яка працювала для мене, де мені довелося спробувати подвійний гіпн у варіанті '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

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


1

для безпеки ми не повинні використовувати самопідписані сертифікати в нашій реалізації. Однак, коли мова заходить про розробку, нам часто доводиться використовувати пробні середовища, які отримали сертифікати самопідписання. Я спробував виправити це питання програмно у своєму коді, і мені не вдалося. Однак, додавши cert до магазину jre trust, я вирішив мою проблему. Нижче наведено кроки,

  1. Завантажте сайт cert,

    • Використання 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 -захист змін

Якщо ви отримали помилку, кажучи, що keytool не впізнаваний, зверніться до цього.

Введіть так, як нижче

Довіряйте цьому сертифікату: [Так]

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

Оновлення

Якщо ваш сервер додатків jboss, спробуйте додати нижче системну властивість

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

Сподіваюся, це допомагає!


1

РЕШЕННЯ РОБОТИ (Alpine Linux)

Щоб виправити цю проблему в наших додатках, ми підготували команди терміналу Linux наступним чином:

cd ~

Згенерує файл cert у домашньому каталозі.

apk add openssl

Ця команда встановлює openssl в альпійському Linux. Ви можете знайти належні команди для інших дистрибутивів Linux.

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

Створено потрібний файл cert.

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'). Ці два властивості дозволять вам використовувати такі сценарії у своїх додатках, як побудова зображення Докера.

Примітка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


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>

0

Я хочу передзвонити, оскільки в мене є середовище QEMU, де мені потрібно завантажувати файли в Java. Виявляється, /etc/ssl/certs/java/cacertsу QEMU є проблеми, оскільки вона не відповідає середовищу /etc/ssl/certs/java/cacertsв хост-середовищі. Хост-середовище стоїть за проксі-сервером компанії, тому java cacerts - це спеціалізована версія.

Якщо ви використовуєте середовище QEMU, переконайтеся, що хост-система спочатку може отримати доступ до файлів. Наприклад, ви можете спробувати цей сценарій на вашій хост-машині першим, щоб побачити. Якщо сценарій працює просто в хост-машині, але не в QEMU, у вас виникають ті ж проблеми, що і у мене.

Щоб вирішити цю проблему, мені довелося зробити резервну копію оригінального файлу в QEMU, скопіювати файл в хост-середовищі до в'язниці chroot QEMU, і тоді java могла нормально завантажувати файли в QEMU.

Кращим рішенням буде встановлення /etcв середовищі QEMU; однак я не впевнений, чи впливатимуть на інші файли в цьому процесі. Тому я вирішив використати цю потворну, але легку обробку.


0

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

Друкарська помилка означала, що я також використовую магазин брелоків як довіру. Оскільки в моїх компаніях Root CA не визначався як окремий сертифікат у сховищі клавіш, а лише як частина ланцюга cert, і його не визначали ніде більше (тобто касети), я продовжував отримувати помилку 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
додайте це до коду. Ні. Не додайте цього до коду . Створення SSLContext таким чином видаляє всі перевірки безпеки, що підтверджують особу сервера, до якого ви підключаєтесь. Відповідь на проблему втрати ключів НЕ видаляйте всі блоки з усього, що у вас є.
Ендрю Генле
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.