For the complete documentation index, see llms.txt. This page is also available as Markdown.

Connection Error: Certification Path Failed/PKIX Path Building Failed

Introduction

This error appears when Getint cannot find a valid certification path while opening a connection to another tool. In practice, it means the Java Virtual Machine (JVM) running Getint does not trust the SSL certificate presented by the target server, so the handshake fails before any data is exchanged.

The fix is almost always the same: add the target server's certificate (and its issuing chain) to the trust store of the JVM that runs Getint, then restart. Most failures after this step come from editing the trust store of a different JDK or JRE than the one Getint actually uses.

When This Happens

Connection problems with tools such as ServiceNow and Azure DevOps commonly appear right after an expired SSL certificate is replaced, or when an on-premise server uses a self-signed certificate. The error returned looks like this:

Request failed with status code 500. PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The JVM rejects the connection because the server's certificate, or one of the certificates above it in the chain, is not present in the JVM trust store.

Before You Begin

Confirm exactly which JDK or JRE runs your Getint on-premise instance. This is the most frequent source of confusion, because a machine can have several Java installations, and editing the wrong trust store has no effect.

  • Check the JAVA_HOME environment variable, or the Java path configured in your service or container.

  • Note the Java version, because the trust store location differs:

    • Java 8 and earlier: JAVA_HOME/jre/lib/security/cacerts

    • Java 9 and later: JAVA_HOME/lib/security/cacerts

  • Have the target server's certificate ready as a .cer or .pem file, including any intermediate and root certificates in the chain.

Troubleshooting Steps

Option A: Import the certificate into the JVM trust store

This is the recommended approach for a self-signed or internal certificate.

  1. Export the certificate chain from the target server, for example, with a browser or with openssl s_client -connect host:443 -showcerts.

  2. Import each certificate into the JVM trust store with keytool:

keytool -importcert \ -alias your-server-name \ -file your-certificate.cer \ -keystore "$JAVA_HOME/lib/security/cacerts"

  1. When prompted for the trust store password, the Java default is changeit unless your environment changed it.

  2. Confirm the import with keytool -list -keystore "$JAVA_HOME/lib/security/cacerts" -alias your-server-name.

  3. Restart the Getint application so the JVM reloads the trust store.

Option B: Point the application at a custom trust store

Use this when you cannot or prefer not to modify the default cacerts file.

  1. Create a dedicated trust store and import the certificate chain into it with the same keytool -importcert command, targeting your custom file.

  2. Start the application with the trust store parameters:

-Djavax.net.ssl.trustStore=/path/to/your-truststore.jks -Djavax.net.ssl.trustStorePassword=your-password

  1. Restart the Getint application and test the connection.

Additional Tips

  • Keep the certificate chain complete: Verify that the leaf, intermediate, and root certificates are all installed and valid on the server, so this does not recur.

  • Plan certificate renewals: Schedule SSL certificate updates and replacements ahead of expiry to avoid sudden connection failures.

  • Consult the platform documentation: Refer to your JVM and server documentation for the exact trust store paths and certificate management commands in your environment.

Atlassian also publishes a guide on this error: Unable to Connect to SSL Services Due to PKIX Path Building Failed Error.

Conclusion

In short, this error is a trust problem rather than a Getint problem. Identify the exact JDK or JRE that runs Getint, import the target server's full certificate chain into that JVM's trust store (or point the app at a custom trust store), and restart. Keeping the chain complete and renewing certificates before they expire prevents it from returning.

If you have further questions or need help with other issues, contact our Support Team.

Last updated

Was this helpful?