java не удалось найти допустимый путь сертификации к запрошенному целевому объекту

#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 должно помочь. Где ты можешь это попробовать? Я могу поделиться некоторыми примерами фрагментов кода