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"
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 isjava-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 thecacerts
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 latestcacerts
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:

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)"):

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 runningjava
orkeytool
from the command line. -
$PATH_TO_PEM_FILE
- This should be the location of thePEM
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.