Open Tiberiu-urss opened 7 years ago
@Tiberiu-urss Hi, if you know what the solution is, could you please submit a pull request? Thanks
@Tiberiu-urss isn't described problem more like a bug of a library which wraps / doesn't expose JAX-RS/Jersey API?
Environment: jersey-client-2.25.1
In development one might wish to use self signed certificates and to ease development one can do something like this: `// Create a trust manager that does not validate certificate chains TrustManager[] trustAllCerts = new TrustManager[] { new X509TrustManager() { @Override public X509Certificate[] getAcceptedIssuers() {return null;} @Override public void checkServerTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {} @Override public void checkClientTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {} } };
// Install the all-trusting trust manager SSLContext sc = SSLContext.getInstance("SSL"); sc.init(null, trustAllCerts, new SecureRandom()); HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());`
This does not work because in org.glassfish.jersey.client.internal.HttpUrlConnector#secureConnection the check
if (HttpsURLConnection.getDefaultSSLSocketFactory() == suc.getSSLSocketFactory())
is true and thesuc.setSSLSocketFactory(sslSocketFactory.get());
overwrites the custom trust manager.There are use cases in which the jersey client is wrapped in custom libraries and it is not exposed as a public API. In such cases the "clean" solution cannot be used by the client of the custom library:
Client client = ClientBuilder.newBuilder().sslContext(ctx).hostnameVerifier(new AllowAllHostsHostNameVerifier()).build()