Редагувати: - На моєму блозі спробували відформатувати питання та прийняту відповідь більш презентабельно

Ось оригінальний випуск.

Я отримую цю помилку:

докладне повідомлення 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());

Потрібно додати сертифікат для 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 визначити значення виразу, і я виявив, що ця проблема виникає, коли сервер змінює свій сертифікат 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.

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

Як працювати - це в 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);

// ...

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

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

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

Джерело

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

Файл моїх кекерів був абсолютно порожнім. Я вирішив це, скопіювавши файл 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коли стикався з тією ж проблемою. Тут я спробував топ-2 рішення (додав сертифікат за допомогою 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 нижче - точна команда, яка працювала для мене, де мені довелося спробувати подвійний гіпн у варіанті '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

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

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

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

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

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

Оновлення

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

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

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

РЕШЕННЯ РОБОТИ (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, ви можете один раз створити секретний файл і помістити його у файли проекту програми. Вам не потрібно буде генерувати його знову і знову.

У мене теж є ця проблема.

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

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

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

Друкарська помилка означала, що я також використовую магазин брелоків як довіру. Оскільки в моїх компаніях Root CA не визначався як окремий сертифікат у сховищі клавіш, а лише як частина ланцюга cert, і його не визначали ніде більше (тобто касети), я продовжував отримувати помилку 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) {
       }