"PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException" - caused by HttpUrlConnector which relies on DefaultSSLSocketFactory value which is not a constant"

[Andremoniy]

https://github.com/eclipse-ee4j/jersey/blob/master/core-client/src/main/java/org/glassfish/jersey/client/internal/HttpUrlConnector.java#L302-L304

HttpUrlConnector sets the custom SSLFactory only when the one in the current HttpsURLConnection instance is the default one:

if (HttpsURLConnection.getDefaultSSLSocketFactory() == suc.getSSLSocketFactory()) {
                // indicates that the custom socket factory was not set
                suc.setSSLSocketFactory(sslSocketFactory.get());
            }

However, there is no guarantee that HttpsURLConnection.getDefaultSSLSocketFactory() remains a constant. Furthermore, there is an open bug about this issue:
https://bugs.openjdk.java.net/browse/JDK-8160347

This leads to the situation when the underlying HttpsURLConnection doesn't receive a custom SSLSocketFactory from the client.

The issue is certainly related to this one: #3293 but the fix was not proposed or has not been merged, so the issue is still remains.

Several screenshots with an evidence of this issue I've caught in debug.
On this screenshot we see that the current instance of HttpUrlConnector has a custom SSLSocketFactory instance with a custom TrustManager with one trusted certificate.

The second screenshot demonstrates, that the uc object still has a default SSLSocketFactory with the default TrustManager containing 88 certificates.

The final screenshot shows that even though both HttpsURLConnection.getDefaultSSLSocketFactory() and suc.getSSLSocketFactory() have the same SSLContext, the instances themselves are not equal.

This causes apparently "PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException" error because of the wrongly configured truststore.

[Andremoniy]

Dear jersey's developers, I have created a test which reproduces the problem.

https://github.com/Andremoniy/jersey-bug-4332/blob/master/src/test/java/com/github/andremoniy/jersey/bug4332/JerseyBug4332Test.java

[schedin]

I ran into this problem as well. Since this ticket and the OpenJDK ticket is still open I'm sharing my (ugly) workaround: Add this line early in your code that is using Jersey:

HttpsURLConnection.getDefaultSSLSocketFactory();

[dcitron]

I have also spent quite a bit of time debugging this issue in my product, only to find that it's been reported variously since 2015 but never fixed.

[msn-tldr]

Same ran into this problem too.

[jansupol]

We would love to fix this, but as mentioned, the bug is in the JDK. Jersey can attempt to provide some workaround but there is always a use-case that gets broken with the workaround.

@msn-tldr What Jersey do you have the problem with? There were some changes in the latest builds, but we are not sure how to overcome the JDK issue for good.