Why my builds are failing with ‘peer not authenticated’ exception on JDK6 builds?

The use case is the following:

Artifactory is behind HTTPS

The CI server (Jenkins for example) is configured to run with JDK 6.

From version 4.0.X Artifactory must be run with JDK8  and above.

When running jobs on Jenkins, they fail with the following exception:

Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated

        at com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)

        at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)

        at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:437)

        at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)

        at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)

        at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:643)

        at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)

        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)

        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)

        at org.jfrog.build.client.PreemptiveHttpClient.execute(PreemptiveHttpClient.java:88)

        at org.jfrog.build.client.ArtifactoryHttpClient.execute(ArtifactoryHttpClient.java:193)

        at org.jfrog.build.client.ArtifactoryHttpClient.upload(ArtifactoryHttpClient.java:189)

        at org.jfrog.build.client.ArtifactoryBuildInfoClient.uploadFile(ArtifactoryBuildInfoClient.java:514)

        at org.jfrog.build.client.ArtifactoryBuildInfoClient.deployArtifact(ArtifactoryBuildInfoClient.java:294)

        at org.jfrog.build.extractor.maven.BuildDeploymentHelper.deployArtifacts(BuildDeploymentHelper.java:270)

        … 30 more

What happened?

There is an ssl conflict between JDK6 and JDK8.

A good indication that JDK is responsible, will be to change the CI server settings to run with JDK7 and above.

How to debug the error to get more details on reason for the exception?

For on the job configuration, add the following debug entry ‘-Djavax.net.debug=all’.

For example, if the CI server is Jenkins, and the job is with Maven, 

First, need to click the Advanced Button

Then, to add this entry on the MAVEN_OPTS field as the following:

How to solve this issue and still use JDK6 which is my requirement?

Please note that to get JDK6 patches requires Oracle enterprise account.

Two common reasons for the ‘peer not authenticated’ exception:

1.  SSL Protocol

Check this regarding the evolution of protocols compare JDK versions.

As a common possible use-case, the exception is a result of a failure with the SSLv2Hello message process.

On the CI server which is configured with JDK6 the SSLv2Hello message is enabled.

On the other hand, Artifactory server runs with JDK8 in which the SSLv2Hello message is disabled by default.

The client – CI Server – tries to send Artifactory the SSLv2Hello message during the SSL handshake. However, on the JDK of the server -Artifactory – the sslv2hello message is disabled. As a result, there is a failure in the SSL handshake process and the exception is thrown – peer not authenticated.

Here is the oracle documentation on the subject: Version 1.6.0_91-b13. This is the version where the the SSL handshake failure was fixed for JDK6 users.

See here for this release bug fixes (in particular, the following case which is the error you are getting).

From JDK 7 onward, the SSLv2Hello message is disabled by default 

Check the following Stackoverflow conversation on the same subject.

2. Certificate  

With verbose debug output, there will be the following exception

Caused by: java.lang.RuntimeException: Could not generate DH keypair

Check the following Stackoverflow conversation on the same subject.

Here is the oracle documentation on the subject. Version 1.6.0_105-b15 is the version where the the DHKey pair was fixed.

For this version, the DHKeyPair generation supports the use of key sizes up to 2048 bits. Key size must be multiples of 64 if less than 1024 bits, or 2048 bits.
Here is the matching issue as a reference.