Allow insecure HTTPS connection for Java JDK 11 HttpClient

As suggested already you need an SSLContext which ignores the bad certificates. The exact code which obtains the SSLContext in one of the links in the question should work by basically creating a null TrustManager which doesn’t look at the certs:

private static TrustManager[] trustAllCerts = new TrustManager[]{
    new X509TrustManager() {
        public java.security.cert.X509Certificate[] getAcceptedIssuers() {
            return null;
        }
        public void checkClientTrusted(
            java.security.cert.X509Certificate[] certs, String authType) {
        }
        public void checkServerTrusted(
            java.security.cert.X509Certificate[] certs, String authType) {
        }
    }
};

public static  void main (String[] args) throws Exception {
    SSLContext sslContext = SSLContext.getInstance("TLS");
    sslContext.init(null, trustAllCerts, new SecureRandom());

    HttpClient client = HttpClient.newBuilder()
        .sslContext(sslContext)
        .build();

The problem with the above is obviously that server authentication is disabled completely for all sites. If there were only one bad certificate then you could import it into a keystore with:

keytool -importcert -keystore keystorename -storepass pass -alias cert -file certfile

and then initialize the SSLContext using an InputStream reading the keystore as follows:

char[] passphrase = ..
KeyStore ks = KeyStore.getInstance("PKCS12");
ks.load(i, passphrase); // i is an InputStream reading the keystore

KeyManagerFactory kmf = KeyManagerFactory.getInstance("PKIX");
kmf.init(ks, passphrase);

TrustManagerFactory tmf = TrustManagerFactory.getInstance("PKIX");
tmf.init(ks);

sslContext = SSLContext.getInstance("TLS");
sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);

Either of the above solutions will work for a self-signed certificate. A third option is in the case where the server provides a valid, non self-signed certificate but for a host which does not match any of the names in the certificate it provides, then a system property “jdk.internal.httpclient.disableHostnameVerification” can be set to “true” and this will force the certificate to be accepted in the same way that the HostnameVerifier API was used previously. Note, that in normal deployments it isn’t expected that any of these mechanisms would be used, as it should be possible to automatically verify the certificate supplied by any correctly configured HTTPS server.