PKIX path building failed error message

Article ID:217078498
4 minute readKnowledge base

Issue

  • I am receiving the following error message:

Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

  • Shared agents do not work on my environment which uses HTTPS.

  • Any error message with ValidatorException: PKIX

  • Jenkins with HTTPS causes PKIX error message.

  • Elasticsearch task that is running in a docker fails with the following error:

"PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target"

Environment

Resolution

The error message:

Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

Is a common error message reported by the Java Virtual Machine. This is caused when the Java environment does not have information about the HTTPS server to verify that it is a valid website.

Possible causes of this issue:

  • If the Java version running on your machine is not up to date, hence the cacerts that is included with your old Java version does not trust the latest Certificate Authorities. Ensure you are running the latest fix pack of Java (for example, for openjdk 1.8, a fix pack level is java-1.8.0-openjdk-1.8.0.191.b12).

  • Running Jenkins with the option -Djavax.net.ssl.trustStore= and pointing to a trust store that was copied from the cacerts of an out-of-date Java fix pack level that does not trust the latest Certificate Authorities. In this case, you may have to rebuild your custom trustStore using the latest cacerts file from the latest Java fixpack version

  • The most common reason for this issue is the certificate is provided by an internal Root CA or is a Self-Signed Certificate. This sometimes can confuse the JVM as it is not one of the ones on the Java "trusted" list who can provide these certificates. The steps to resolve this are listed below:

Because we know that the certificate is "valid" we can import this certificate directly into the JVM. In doing so, we tell the JVM that this is is a "trusted" certificate and to "ignore" any issues with it.

Steps to resolve the issue:

1 . Export the certificate in pem format, which can be done via the command line, or a web browser:

1a . Exporting a certificate using the command line (change www.example.com in this command to the site that is not trusted by the JVM):

openssl s_client -showcerts -connect www.example.com:443 </dev/null 2>/dev/null|openssl x509 -outform PEM > cert.pem

1b . Exporting the certificate using a web browesr:

Note In this example I will be using firefox. Similar steps are available for all other browsers.

To begin we first need to navigate via the browser to the URL where the certificate is located. Clicking on the green lock will show us information about the certificate. After clicking on the green lock click on More Information:

Once you click on the green lock, then a new box will appear with more information about the certificate. Click "View Certificate":

Click the "Details" tab which will provide detailed information about the certificate:

export certificate

Click on the "Export…​" to export this certificate to local disk. Also make sure to maintain the PEM format. (Note: In Windows, the PEM format is called "Base-64 encoded X.509 (.CER)"):

save certificate

2 . Optionally, make a copy of your JVM’s cacerts file to a new directory $LOCAL_DIRECTORY (the benefit of this is: when the JVM is upgraded, the cacerts is not replaced by the upgrade):

mkdir $LOCAL_DIRECTORY
cp $JAVA_HOME/jre/lib/security/cacerts $LOCAL_DIRECTORY/

3 . Open up a terminal and import the certificate into the JVM using the following command:

keytool -import -alias $ALIAS -keystore $JAVA_HOME/jre/lib/security/cacerts -file $PATH_TO_PEM_FILE

Please replace the following:

  • $ALIAS - This can be any value. It is a value to distinguish this certificate from others. Example would be "svn-repo", or "artifact server".

  • $JAVA_HOME - This should be the location of where your current java home is. If you only have the Java Runtime Environment (JRE) installed, then you can replace $JAVA_HOME/jre with the $JRE_HOME. Note: Windows users should verify that they are importing the certificate into the JRE Jenkins runs in. When set up as a Windows service, Jenkins uses the version of Java defined in $JENKINS_HOME\jenkins.xml. This can be a different version of Java than the one which gets invoked by running java or keytool from the command line.

  • $PATH_TO_PEM_FILE - This should be the location of the PEM file we downloaded from above.

4 . The final step is to make sure that the JVM uses the correct cacerts file. To do this please add the following arguments to your Jenkins Java startup process:

-Djavax.net.ssl.trustStore=$PATH_TO_TRUSTSTORE/cacerts
-Djavax.net.ssl.trustStorePassword=changeit

The trustStore argument makes sure that the Java process uses the correct cacerts file. The $PATH_TO_TRUSTSTORE would either be $LOCAL_DIRECTORY/cacerts if you did step 2, or $JAVA_HOME/jre/lib/security/cacerts if you skipped step 2.

After restarting Jenkins it should recognize that the certificate has been added to the "trusted" list and you will no longer encounter the issue.

If the issue persists, test the cacerts file using jrunscript as documented in: Validate the truststore outside Jenkins.

Other Resources