Unable to connect to SSL services due to "PKIX Path Building Failed" error

プラットフォームについて: Server と Data Center のみ - この記事は、サーバーおよびデータセンター プラットフォームのアトラシアン製品にのみ適用されます。

このページの内容は、サポート対象外のプラットフォームに関連しています。したがって、アトラシアンは、そのためのサポートの提供を保証できません 。この資料は情報提供のみを目的としているため、お客様自身の責任でご使用ください。


SSL で暗号化された アプリケーション(HTTPS、LDAPS、IMAPS など)にアクセスしようとすると、例外をスローし、接続が拒否されます。これは、以下のいずれかに対するセキュアな接続を確立しようとした場合に発生する可能性があります。

  • Active Directory server, JIRA User Server or Crowd
  • メール サーバー 
  • アプリケーション リンクを使用した別の Atlassian アプリケーション

たとえば、JIRA 課題マクロを使用すると、以下のエラーが UI に表示されます。

Error rendering macro: java.io.IOException: Could not download: https://siteURL/jira/secure/IssueNavigator.jspa?view=rss&&type=12&type=4&type=3&pid=10081&resolution=1&fixfor=10348&sorter/field=issuekey&sorter/order=DESC&sorter/field=priority&sorter/order=DESC&tempMax=100&reset=true&decorator=none


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


Use SSL Poke to verify connectivity

Try the Java class SSLPoke to see if your truststore contains the right certificates. This will let you connect to a SSL service, send a byte of input, and watch the output.

  1. SSLPoke.class をダウンロードします。
  2. Execute the class as per the below, changing the URL and port appropriately. Take care that you are running the same Java as what Confluence is running with. If you used the installer you will need to use <confluence-home>/jre/java

    $JAVA_HOME/bin/java SSLPoke jira.example.com 443

    A mail server may be mail.example.com 465 .


$JAVA_HOME/bin/java SSLPoke jira.example.com 443
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(PKIXValidator.java:387)
	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
	at sun.security.validator.Validator.validate(Validator.java:260)
	at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324)
	at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:229)
	at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:124)
	at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1351)
	at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:156)
	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:925)
	at sun.security.ssl.Handshaker.process_record(Handshaker.java:860)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1043)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1343)
	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:728)
	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:138)
	at SSLPoke.main(SSLPoke.java:31)
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:145)
	at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:131)
	at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)
	... 15 more


$JAVA_HOME/bin/java SSLPoke jira.example.com 443
Successfully connected

If -Djavax.net.ssl.trustStore is present in your JVM arguments, Java will use the keystore specified with that argument. You can verify whether the -Djavax.net.ssl.trustStore parameter is causing problems by running the SSLPoke test and specifying the same JVM argument to use that keystore. For example:

$JAVA_HOME/bin/java -Djavax.net.ssl.trustStore=/my/custom/truststore SSLPoke jira.example.com 443

If this fails (confirming the problem that the truststore doesn't contain the appropriate certificates), then the certificate will need to be imported into that truststore as per the instructions in Connecting to SSL Services.


Whenever Java attempts to connect to another application over SSL (e.g.: HTTPS, IMAPS, LDAPS), it will only be able to connect to that application if it can trust it. The way trust is handled in the Java world is that you have a keystore (typically $JAVA_HOME/lib/security/cacerts), also known as the truststore. This contains a list of all known Certificate Authority (CA) certificates, and Java will only trust certificates that are signed by one of those CAs or public certificates that exist within that keystore. For example, if we look at the certificate for Atlassian, we can see that the *.atlassian.com certificate has been signed by the intermediate certificates, DigiCert High Assurance EV Root CA and DigiCert High Assurance CA-3. These intermediate certificates have been signed by the root  Entrust.net Secure Server CA :

These three certificates combined are referred to as the certificate chain, and, as they are all within the Java keystore (cacerts), Java will trust any certificates signed by them (in this case, *.atlassian.com). Alternatively, if the *. atlassian.com  certificate had been in the keystore, Java would also trust that site.

そのため、この問題は、自己署名証明書(CA が署名していない)または Java トラストストアに存在しない証明書チェーンによって引き起こされます。Java はその証明書を信用せず、アプリケーションへの接続に失敗します。


  1. Make sure you have imported the public certificate of the target instance into the truststore according to the Connecting to SSL Services instructions.
  2. Make sure any certificates have been imported into the correct truststore; you may have multiple JRE/JDKs. See Installing Java for this.
  3. Check to see that the correct truststore is in use. If -Djavax.net.ssl.trustStore has been configured, it will override the location of the default truststore, which will need to be checked.
  4. If this error results while integrating with an LDAP server over LDAPS and there is more than one LDAP server, then deselect the Follow referrals option within the LDAP user directory configuration per Connecting to and LDAP Directory.  Optionally, import the SSL certificates from the other LDAP servers into the Confluence truststore.
  5. Check if your Anti Virus tool has "SSL Scanning" blocking SSL/TLS. If it does, disable this feature or set exceptions for the target addresses (check the product documentation to see if this is possible.)
  6. Exchange などのメール サーバーに接続する場合、認証情報がプレーン テキストであることを確認します。
  7. ターゲット サーバーが正しく SSL をサービスするように設定されていることを確認します。これはSSL サービス テスト ツールで実施することができます。
  8. If all else fails, your truststore might be out of date. Upgrade Java to the latest version supported by your application.


Since the keystore only gets read once when the JVM is initialized, please restart the source application service after importing the new certificate(s).


Attempting to access applications that are encrypted with SSL throws an exception and the connection is refused. This can happen when attempting to connect securely to other systems such as Active Directory, another Atlassian application, and mail servers.

製品Jira, Confluence, Bamboo, Bitbucket, Fisheye, Crucible, Crowd
プラットフォームServer, Data Center
最終更新日 2020 年 6 月 26 日


Powered by Confluence and Scroll Viewport.