#java #ssl #ssl-certificate
Вопрос:
Этот вопрос задавался несколько раз.
Ответы всегда таковы: «добавьте сертификат в хранилище доверия».
Мне приходится работать через странный прокси-сервер, который всегда отправляет разные самозаверяющие сертификаты. Следовательно, добавление в truststore нецелесообразно.
Единственный вариант-отключить проверку сертификатов SSL. У меня есть этот код, но он не помогает 🙁 Есть предложения)?
(Кстати, меня не волнует безопасность, мы используем этот код внутри компании для тестирования)
@Slf4j
public class TrustAllX509TrustManager implements X509TrustManager {
@SneakyThrows({ KeyManagementException.class,
NoSuchAlgorithmException.class })
public static void disableSslCertificateValidation() {
log.debug("turning off SSL certificate validation");
val sslContext = SSLContext.getInstance("TLS");
sslContext.init(null,
new TrustManager[] { new TrustAllX509TrustManager() },
new java.security.SecureRandom());
HttpsURLConnection
.setDefaultSSLSocketFactory(sslContext.getSocketFactory());
HttpsURLConnection
.setDefaultHostnameVerifier((string, ssls) -> true);
}
@Override
public void checkClientTrusted(
final java.security.cert.X509Certificate[] certs,
final String authType) {
// nothing to do here
}
@Override
public void checkServerTrusted(
final java.security.cert.X509Certificate[] certs,
final String authType) {
// nothing to do here
}
@Override
public X509Certificate[] getAcceptedIssuers() {
return new X509Certificate[0];
}
}
Ответ №1:
Похоже, что вы используете пользовательскую реализацию X509TrustManager. У меня была аналогичная проблема, что и у вас, и я решил ее с помощью другого базового менеджера доверия.
Поэтому то, что я сделал, было вместо реализации X509TrustManager
, с помощью которой я расширил свой пользовательский доверительный менеджер X509ExtendedTrustmanager
. См. Здесь пример: UnsafeX509ExtendedTrustManager
Я обнаружил, что java оборачивает TrustManager в пользовательский TrustManager типа X509ExtendedTrustmanager
, который не отключает все проверки, как вы сделали в своем фрагменте, если это экземпляр X509TrustManager
. Поэтому, я думаю, использование пользовательского доверительного управляющего такого типа X509ExtendedTrustmanager
должно сделать то, что я думаю. Можете ли вы попробовать и поделиться своими результатами?
Комментарии:
1. Похоже, что Java все еще не имеет стандартного способа HTTP-связи, и каждая библиотека должна быть настроена немного по-другому. Для клиента JAX-RS при настройке клиента необходимо задать определенный SSLContext. Существуют и другие клиенты HTTP/REST, и, возможно, каждый из них имеет свой собственный уникальный способ. В настоящее время я застрял с AmazonHttpClient-открыл проблему по адресу github.com/aws/aws-sdk-java/issues/2603
2. Спасибо, что поделились ссылкой на проблему, посмотрев на stackstrace, которым вы поделились на github, я почти уверен, что использование X509ExtendedTrustManager вместо X509TrustManager должно помочь. Где ты можешь это попробовать? Я могу поделиться некоторыми примерами фрагментов кода