Разрешение javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: сбой построения пути PKIX Ошибка?
Изменить:- Попытался отформатировать вопрос и принял ответ более презентабельным способом в моем блоге
Вот оригинальная проблема:
Я получаю эту ошибку
подробное сообщение 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, установленные на разных Tomcat на другой порт, но на одной машине. Сказать App1(port 8443) а также App2(port 443), App1 подключается к App2.Когда App1 подключается к App2 i получить выше ошибка. Я знаю, что это очень распространенная ошибка, поэтому сталкивался со многими решениями на разных форумах и сайтах. У меня ниже запись в server.xml оба кота то есть
keystoreFile="c:/.keystore"
keystorePass="changeit"
На каждом сайте указывается одна и та же причина, по которой сертификат, предоставленный app2, отсутствует в доверенном хранилище app1 jvm. Кажется, это также верно, когда мне надоело нажимать один и тот же URL-адрес в браузере IE, он работает (с потеплением. Существует проблема с сертификатом безопасности этого веб-сайта. Здесь я говорю "перейти на этот веб-сайт"), но когда тот же URL-адрес удаляется Java-клиент (в моем случае). Так что я получаю вышеуказанную ошибку. Таким образом, чтобы поместить это в trustore, я попробовал эти варианты дерева, т.е.
Опция 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
Вариант 3 Настройка ниже в переменной среды
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());
38 ответов
Вам необходимо добавить сертификат для 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 location, и пароль по умолчанию для доступа: changeit.
Для просмотра информации о каскадах необходимо выполнить следующие процедуры:
• Нажмите кнопку Пуск -> Выполнить
• Введите cmd. Откроется командная строка (может потребоваться открыть ее как администратор).
• Перейти к вашей Java/jreX/bin каталог
• Введите следующее
keytool -list -keystore D:\Java\jdk1.5.0_12\jre\lib\security\cacerts
Это дает список текущих сертификатов, содержащихся в хранилище ключей. Это выглядит примерно так:
C: \ Documents and Settings \ NeelanjanaG> keytool -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 г., доверенный центр,
Отпечаток сертификата (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 г.,rustCertEntry,
Отпечаток сертификата (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 файл в Java cacerts хранилище сертификатов
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) Взломать это
Хотя я установил мой сертификат в 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.
Ниже код работает для меня:
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());
Другой причиной может быть устаревшая версия JDK. Я использовал jdk версии 1.8.0_60, просто обновление до последней версии решило проблему с сертификатом.
Я использовал jdk1.8.0_171 когда я столкнулся с той же проблемой. Я попробовал два лучших решения здесь (добавление сертификата с помощью keytool и другого решения, в котором есть хак), но они не сработали для меня.
Я обновил свой JDK до 1.8.0_181 и это сработало как шарм.
Используя 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
Мой файл 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
Пока все отлично работает.
РАЗВЕРГАЕМОЕ РЕШЕНИЕ (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, вы можете один раз сгенерировать секретный файл и поместить его в файлы проекта приложения. Вам не нужно будет генерировать его снова и снова.
Для меня эта ошибка также возникла при попытке подключиться к процессу за обратным прокси-сервером NGINX, который обрабатывал SSL.
Оказалось, что проблема заключалась в сертификате без объединения всей цепочки сертификатов. Когда я добавил промежуточные сертификаты, проблема была решена.
Надеюсь это поможет.
Если вы используете JDK 11, в папке больше нет JRE. Расположение сертификатов - jdk-11.0.11/lib/security/cacerts.
Для безопасности мы не должны использовать самозаверяющие сертификаты в нашей реализации. Тем не менее, когда речь заходит о разработке, нам часто приходится использовать пробные среды с самоподписанными сертификатами. Я попытался исправить эту проблему программно в моем коде, и мне это не удалось. Однако добавление сертификата в jre trust-store решило мою проблему. Пожалуйста, найдите ниже шаги,
Скачать сайт сертификата,
Скопируйте сертификат (например, cert_file.cer) в каталог $JAVA_HOME\Jre\Lib\Security
Откройте CMD в Администраторе и измените каталог на $JAVA_HOME\Jre\Lib\Security
Импортируйте сертификат в доверенное хранилище, используя следующую команду:
keytool -import -alias ca -file cert_file.cer -keystore cacerts -storepass changeit
Если вы получили сообщение о том, что keytool не распознается, обратитесь к этому.
Тип да как ниже
Доверяйте этому сертификату: [Да]
- Теперь попробуйте запустить свой код или получить доступ к URL программно с помощью Java.
Надеюсь это поможет!
Кажется, это самое подходящее место для документирования еще одной возможной причины печально известного сообщения об ошибке PKIX. Потратив слишком много времени на просмотр содержимого хранилища ключей и доверенного хранилища и различных конфигураций установки Java, я понял, что моя проблема заключалась в... опечатке.
Опечатка означала, что я также использовал хранилище ключей в качестве хранилища доверенных сертификатов. Поскольку корневой центр сертификации моей компании не был определен как отдельный сертификат в хранилище ключей, а только как часть цепочки сертификатов и не был определен где-либо еще (например, cacerts), я продолжал получать ошибку PKIX.
После неудачного выпуска (это prod config, в других местах все было нормально) и двух дней царапины в голове я наконец увидел опечатку, и теперь все в порядке.
Надеюсь, это кому-то поможет.
Для меня не сработало признанное решение из этого сообщения: /questions/20319055/razreshenie-javaxnetsslsslhandshakeexception-sunsecurityvalidatorvalidatorexception-sboj-postroeniya-puti-pkix-oshibka/20319065#20319065.
Вместо этого мне удалось решить проблему, импортировав сертификат в доверенные сертификаты моей машины.
Шаги:
- Перейдите по URL-адресу (например,
https://localhost:8443/yourpath) где сертификация не работает. - Экспортируйте сертификацию, как описано в упомянутом посте.
- На вашем компьютере с Windows откройте:
Manage computer certificates - Идти к
Trusted Root Certification Authorities->Certificates - Импортируйте сюда свой
your_certification_name.cerфайл.
Я написал небольшой сценарий 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
Чтобы 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 по умолчанию находится здесь. Вставьте недоверенный сертификат в него.
Я использую флаттер и получил эту ошибку из ниоткуда. Итак, что в основном происходит, так это то, что строки в ваших зависимостях внутри
android/build.gradle файл, такой как:
classpath 'com.android.tools.build:gradle:4.1.0'
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
требуется подтверждение того, что файл оценок загружается из Интернета. Но когда есть что-то, что блокирует gradle для загрузки этих сертификатов, это обычно отображается.
Я попытался экспортировать сертификат и добавить его вручную, но, похоже, у меня это не сработало. После бесчисленных царапин на голове у меня сработало отключение прокси в настройках сети. Где-то упоминалось, что отключение Чарльза Прокси исправит это, но в тот момент я понятия не имел, что такое Чарльз и что такое прокси. А в моем случае у меня не было прокси Charles, поэтому я продолжил поиск прокси в настройках сетевых настроек на Mac(его можно было найти где-нибудь в сетевых настройках для Windows). У меня были включены Socks в прокси. Я отключил его, а затем снова перестроил градл и ТА-ДА !!! Это работало как масло.
Следует запомнить несколько вещей. Если вы создадите свой проект сразу после отключения прокси, не закрывая вкладку сетевых настроек, отключение прокси не будет работать, и будет отображаться та же ошибка. Кроме того, если вы уже создали проект и снова запускаете его после отключения прокси, скорее всего, он покажет ту же ошибку (может быть из-за кешей IDE). Как это сработало для меня: перезагрузите Mac, откройте несколько вкладок в браузере (для нескольких сетевых вызовов), проверьте сетевые настройки в системных настройках >> Wi-Fi и отключите прокси, закройте приложение системных настроек и создайте проект.
Мои два цента: В моем случае cacerts был не папкой, а файлом, а также был представлен на двух путях. После обнаружения ошибка исчезла после копирования файла.jks поверх этого файла.
# locate cacerts
/usr/java/jdk1.8.0_221-amd64/jre/lib/security/cacerts
/usr/java/jre1.8.0_221-amd64/lib/security/cacerts
После их резервного копирования я копирую.jks.
cp /path_of_jks_file/file.jks /usr/java/jdk1.8.0_221-amd64/jre/lib/security/cacerts
cp /path_of_jks_file/file.jks /usr/java/jre1.8.0_221-amd64/lib/security/cacerts
Примечание: этот базовый прием разрешает эту ошибку в проекте Genexus, несмотря на то, что file.jks также находится в файле server.xml Tomcat.
Я получал эту ошибку в Android Studio. Итак, я сделал это после долгих исследований.
Пароль changeit для cacert
Шаг 1: Откройте CMD от имени администратора.
Шаг 2: Введите «Powershell»
Шаг 3: start-process powershell -verb runas
Шаг 4: Добавьте все свои сертификаты в C:\Program Files\Android\Android Studio\jre\lib\security в это место, где доступен cacert.
Шаг 5: Перейдите в каталог Keytool Set-Location -Path "C:\Program Files\Android\Android Studio\jre\bin"
Шаг 6: выполните эту команду в powershell.\keytool -importcert -trustcacerts -alias GiveNameforyourcertificate -file "C:\Program Files\Android\Android Studio\jre\lib\security\Replace With Your Certificate name.cer"
Шаг 7. Если при добавлении сертификата возникает ошибка (отказано в доступе), создайте раздел диска D (https://www.diskpart.com/windows-10/how-to-create-d-drive-from-c-drive-in-windows-10-0725.html) или переместите файл на диск d, затем добавьте сертификат
Если вы сохранили свой файл на диске D, выполните только это
Шаг 8: keytool -importcert -trustcacerts -alias Nameyourcertificate -file "D:\Certificatename.cer" -keystore cacerts
Шаг 9. Проверьте, был ли добавлен сертификат с помощью этой команды.\keytool -list -keystore cacerts
У меня тоже есть эта проблема.
Я попробовал почти все, добавив сертификат SSL в.keystore, но он не работал с Java1_6_x. Для меня это помогло, если бы мы начали использовать более новую версию Java, Java1_8_x в качестве JVM.
Я хочу вмешаться, поскольку у меня есть среда QEMU, в которой мне нужно загружать файлы в формате java. Оказывается/etc/ssl/certs/java/cacerts в QEMU действительно есть проблема, потому что он не соответствует /etc/ssl/certs/java/cacertsв среде хоста. Среда хоста находится за прокси-сервером компании, поэтому java cacerts является настраиваемой версией.
Если вы используете среду QEMU, сначала убедитесь, что хост-система может получить доступ к файлам. Например, вы можете сначала попробовать этот сценарий на своем хост-компьютере, чтобы увидеть. Если скрипт работает нормально на хост-машине, но не в QEMU, значит, у вас та же проблема, что и у меня.
Чтобы решить эту проблему, мне пришлось сделать резервную копию исходного файла в QEMU, скопировать файл в среде хоста в chroot-тюрьму QEMU, а затем java могла нормально загружать файлы в QEMU.
Лучшим решением было бы установить /etcв среду QEMU; однако я не уверен, повлияет ли этот процесс на другие файлы. Поэтому я решил использовать этот уродливый, но простой обходной путь.
У нас тоже была такая же проблема, и мы сделали все следующие вещи.
- SSL-сертификаты сервера повторно импортированы.
- Убедитесь, что weblogic использует правильные caecerts.
Наконец, наша weblogic включила режим weblogic DEBUG и обнаружила исключение «NOT HANDSHAKED».
Причина, по которой мы обнаружили, заключается в том, что клиентская система использует jdk 1.6, а сервер использует более высокую версию jdk (1.8), из-за которой возникает некоторое несоответствие версии TLS, вызывающее проблему.
Команда Weblogic изменила конфигурацию сервера, добавив следующие строки в аргументы сервера.
-Djdk.tls.client.protocol=TLSv1.2 -DUseSunHttpHandler=true.
В моем случае проблемой был Charles Mac Os Proxy.
Действия по решению -
- Если charles активирован/открыт, перейдите в меню «Прокси», снимите флажок «Прокси-сервер Mac OS X».
- Завершите все Java-процессы с помощью приложения «Монитор активности» и повторите попытку.
Недостаток Java - не использовать стандартное хранилище ключей операционной системы, как в MacOS X. Сегодня я подал запрос на изменение, см. http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8185892
Я столкнулся с этой проблемой сегодня (та же ошибка PKIX) после настройки нового проекта и был полностью сбит с толку, поскольку ранее я импортировал свой сертификат безопасности для своей организации, выполнив действия, описанные выше. На самом деле, проект, выполняющий аналогичную функцию, не имел этой проблемы.
Я понял, что версия библиотеки MS SQL JDBC, которую взял Gradle, была самой новой (12.2.0.jre8 на момент этого ответа), а в другом моем проекте использовалась версия 8.4.1.jre8. Как только я указал старую версию, я начал работать.
Я понимаю, что этот ответ не объясняет, что именно в новой версии вызывает проблему, но я надеюсь, что это поможет кому-то в крайнем случае. Я уже потратил на это много времени.
Мой проект использует Spring Boot, оболочку Gradle, Java 8, JPA и MS SQL Server.
Глядя на содержимое различных сертификатов и сертификатов, сгенерированных с помощью стандартной процедуры openssl, я заметил, что AutorityKeyIdentifier был установлен для корневого сертификата openssl самому себе. Возможно, есть способ преодолеть это... но я его не знаю...
Затем я разработал небольшое приложение с Java11 и BouncyCastle для генерации корневых сертификатов и ключей, теперь на github: https://github.com/kendarorg/JavaCaCertGenerator
Корневые сертификаты, сгенерированные с помощью этого инструмента, НЕ СОДЕРЖАТ AuthorKeyIdentifier и могут быть установлены с помощью keytool непосредственно в хранилище cacert. Когда я создам файл csr и ext с доменными именами, это будет проверено на соответствие хранилищу cacert, содержащему корень... и больше никаких исключений рукопожатия!
Может быть, cacert не допускает рекурсивного AuthorKeyIdentifier? Я не знаю, но я буду признателен за обзор :)
Следите за отличным ответом для @NDeveloper, я скопировал вставку, конечно, изменив значения, и я получал
Illegal option: ?import
Я проверил дефисы, и я увидел, что в этом ответе был обман с использованием ascii
– 8211
Если у вас возникают проблемы, проверьте, что код ascii, который помог мне, был следующим: code = 45
- 45
Мой код
keytool -import -noprompt -trustcacerts -alias Certificado -file "C:\Users\JavIut\Desktop\Company\Certificados\Certificado.cer" -keystore "C:\Program Files\Java\jdk1.8.0_121\jre\lib\security\cacerts"
Я надеюсь, что поможет кому-нибудь, спасибо привет из Венесуэлы.
Я искал аналогичную проблему, потому что мне нужно безопасно обслуживать угловые приложения в локальном домене, например example.com.
Чтобы создать сертификат,
openssl req -newkey rsa:2048 -x509 -nodes -keyout server.key -new -out server.crt -config ./openssl-custom.cnf -sha256 -days 3650
openss-custom.cnf
[req]
default_bits = 2048
prompt = no
default_md = sha256
x509_extensions = v3_req
distinguished_name = dn
[dn]
C = TR
ST = Ankara
L = Ankara
O = Example
OU = Angular
emailAddress = angular@example.com
CN = *.example.com
[v3_req]
subjectAltName = @alt_names
[alt_names]
DNS.1 = *.example.com
Даже если я импортирую этот сертификат в сертификаты активного jre, загрузочное приложение Spring не будет работать должным образом. И была выдана ошибка «trustAnchor не должна быть пустой». Потому что jvm не содержал моего хранилища доверенных сертификатов. Чтобы решить эту проблему, хранилище доверенных сертификатов должно быть передано параметру jvm.
Установите эти параметры на стороне загрузки пружины
@Configuration
public class SSLConfig {
@Autowired
private Environment env;
@PostConstruct
private void configureSSL() {
//load the 'javax.net.ssl.trustStore' and
//'javax.net.ssl.trustStorePassword' from application.properties
System.setProperty("javax.net.ssl.trustStore", env.getProperty("server.ssl.trust-store"));
System.setProperty("javax.net.ssl.trustStorePassword",env.getProperty("server.ssl.trust-store-password"));
}
}
application.properties:
server.ssl.trust-store: YOUR_TRUST_STORE_PATH
server.ssl.trust-store-password: YOUR_TRUST_STORE_PASSWORD
или установите параметр jvm при запуске Java-приложения
-Djavax.net.ssl.trustStore
-Djavax.net.ssl.trustStorePassword