Às vezes, é necessário permitir conexões HTTPS inseguras, por exemplo em alguns aplicativos de rastreamento da web que devem funcionar com qualquer site. Eu useium tal solução com a antiga API HttpsURLConnection, que foi substituída recentemente pelonew HttpClient API no JDK 11. Qual é a maneira de permitir conexões HTTPS inseguras (certificado autoassinado ou expirado) com esta nova AP

UPD: O código que tentei (no Kotlin, mas mapeia diretamente para Java):

    val trustAllCerts = arrayOf<TrustManager>(object: X509TrustManager {
        override fun getAcceptedIssuers(): Array<X509Certificate>? = null
        override fun checkClientTrusted(certs: Array<X509Certificate>, authType: String) {}
        override fun checkServerTrusted(certs: Array<X509Certificate>, authType: String) {}
    })

    val sslContext = SSLContext.getInstance("SSL")
    sslContext.init(null, trustAllCerts, SecureRandom())

    val sslParams = SSLParameters()
    // This should prevent host validation
    sslParams.endpointIdentificationAlgorithm = ""

    httpClient = HttpClient.newBuilder()
        .sslContext(sslContext)
        .sslParameters(sslParams)
        .build()

Mas ao enviar eu tenho exceção (experimentando localhost com certificado autoassinado):

java.io.IOException: No name matching localhost found

O uso do endereço IP em vez do host local gera a exceção "Nenhum nome alternativo de assunto presente"

Após alguma depuração do JDK, descobri quesslParams são realmente ignorados no local em que a exceção é lançada e alguma instância criada localmente é usada. Depuração adicional revelou que a única maneira de afetar o algoritmo de verificação de nome de host é definirjdk.internal.httpclient.disableHostnameVerification propriedade do sistema para true. E isso parece ser uma solução.SSLParameters no código acima não tem efeito, portanto esta parte pode ser descartada. Torná-lo configurável apenas globalmente parece uma falha grave de design na nova API HttpClien