SSL problems during export - unable to find valid certification path to requested target

As described here, Scroll Exporters and Scroll Versions integrate with each other using a REST API which is based on HTTP or HTTPS.

In some scenarios with HTTPS / SSL you may run into errors during exports because the Java Virtual Machine can not validate the SSL certificate of your Confluence server.

This problem might also occur when using Backbone Issue Sync for JIRA with a conflict and the following message:

The server '<servername>' is not reachable: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderExcpetion: unable to find valid certification path to request target.

Problem

  • Exporting of pages in a space managed by Scroll Versions fails.
  • Common Web Browsers have no problems in validating the certificate when browsing the Confluence pages.
  • The Confluence log contains an error like this:

2014-03-07 09:20:57,991 ERROR [pool-11-thread-2] [scroll.core.io.Resource] getContentAsStream Loading resource from '{https://my-server:8444/rest/scroll-versions/1.0/export-pagetree?pageId=9568258&languageKey=en&pageSelectionStrategyId=com.k15t.scroll.scroll-pdf:pageonly&pageSelectionStrategyProperties=%7B%7D}' failed.
 -- url: /rest/scroll-pdf/1.0/export | userName: someuser | referer: https://my-server:8444/display/ABC/TestPage
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
	at sun.security.ssl.Alerts.getSSLException(Unknown Source)
	at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
	at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
	at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
	at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
	at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
	...
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.validator.PKIXValidator.doBuild(Unknown Source)
	at sun.security.validator.PKIXValidator.engineValidate(Unknown Source)
	at sun.security.validator.Validator.validate(Unknown Source)
	at sun.security.ssl.X509TrustManagerImpl.validate(Unknown Source)
	at sun.security.ssl.X509TrustManagerImpl.checkTrusted(Unknown Source)
	at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source)
	... 73 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(Unknown Source)
	at java.security.cert.CertPathBuilder.build(Unknown Source)
	... 79 more
CODE

Environment

Products:

  • All Confluence versions
  • All Exporter versions
  • All Scroll Versions versions
  • All JIRA versions
  • All Backbone Issue Sync for JIRA versions

Certificate Types:

  • You are using a self-signed certificate.
  • Your certificate has been signed by a common CA (Certificate Authority) using an intermediate certificate, but their intermediate certificate is not served by your web server.
  • Both the server certificate and the CA intermediate certificate are served by your web server, but the Java truststore does not contain the root certificate.

Resolution

Depending on your type of certificate follow one of these sections.

Note

We're using the third party open source tool 'Portecle' for managing Java truststores because we find it easier to use than the command line program 'keytool' that is shipped with Java.

Of course we cannot give any guarantees, so use it at your own risk.

Download Portecle here: http://portecle.sourceforge.net

Self-signed Certificates

  1. Open the Java truststore using Portecle:
    1. The truststore is usually located at <JAVA_HOME>/jre/lib/security/cacerts
    2. The default password for the truststore is 'changeit' (without the ticks).
  2. Add your self-signed certificate to the Java truststore.
    1. In Portecle add the certificate using Tools > Import Trusted Certificate ...
    2. Save the truststore.
  3. Restart Confluence.

Note

Whenever you update the Java installation on your server, it is very likely that the truststore will be overwritten.

Therefore you'll either need to backup the truststore before doing the update and restore it afterwards or you'll need to add the certificates again.

CA-signed Certificates

For CA-signed certificates you have two options:

  1. Recommended Solution: Make sure that your web server serves both your server certificate and the CA's intermediate certificate. Add the CA's root certificate to your truststore only if not already present.
     (info) This is the recommended solution if the truststore already contains the CA's root certificate because you won't need to add it again after each Java update.
  2. Alternative Solution: Let your web server serve the server certificate only and add both the CA's root and intermediate certificates to your truststore.

Recommended Solution Steps

  1. Combine your server certificate with the intermediate certificate file:
    1. For certificates in PEM format simply copy the two certificate files together into one file:

      cat server.crt ca-intermediate.crt >> combined.crt
      CODE

      See here for further information and format conversion examples: https://support.ssl.com/Knowledgebase/Article/View/19/0/der-vs-crt-vs-cer-vs-pem-certificates-and-how-to-convert-them

    2. If your certificate is stored in a Java keystore simply use Portecle to open it and then import the intermediate certificate using Tools > Import Trusted Certificate ...
  2. You may need to restart your reverse proxy or Confluence now.
  3. Open the Java truststore using Portecle:
    1. The truststore is usually located at <JAVA_HOME>/jre/lib/security/cacerts
    2. The default password for the truststore is 'changeit' (without the ticks).
  4. Go to  Examine > Examine SSL / TLS Connection and enter the address of your server.
    The result should display two certificates when using a CA-signed certificate:
    1. The server's certificate:

    2. The intermediate certificate:

  5. If the dialog shows only one certificate, then your web server does not serve the CA intermediate certificate.

Alternative Solution Steps

  1. Open the Java truststore using Portecle:
    1. The truststore is usually located at <JAVA_HOME>/jre/lib/security/cacerts
    2. The default password for the truststore is 'changeit' (without the ticks).
  2. Add both the CA's root and intermediate certificates to the truststore.
    1. In Portecle check the list for the certificates you want to add first.
    2. If they already exist (with the same details and fingerprints) there is no need to add them again.
    3. Otherwise add the certificates using Tools > Import Trusted Certificate ...
      Usually the root and intermediate certificates can be downloaded from the CA's website.
  3. Save the truststore.
  4. Restart Confluence.

Note

Whenever you update the Java installation on your server, it is very likely that the truststore will be overwritten.

Therefore you'll either need to backup the truststore before doing the update and restore it afterwards or you'll need to add the certificates again.

Cause

This happens because the Java HTTPS client cannot build the complete SSL signature chain for your server's SSL certificate.

Therefore it cannot verify the identity of your server, which is a critical part of SSL-encrypted connections.

Cookie Notice

We use cookies to create a secure and effective browsing experience for our website visitors and to understand how you use our site (i.e. Google Analytics). For more information:
Click Here

OK Don't track me.