Unable to Connect to SSL Services Due to 'PKIX Path Building Failed' Error

問題

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

• Active Directory サーバー、Jiraのユーザー サーバー、Crowd
• メール サーバー 
• アプリケーション リンクを使用した別の Atlassian アプリケーション
• Atlassian Marketplace
• アトラシアン移行サービス

たとえば、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

診断

1. SSLPoke.class をダウンロードします。

2. 以下のとおりにクラスを実行します。URL とポートは必要に応じて変更します。アプリケーション (Confluence、Jira など) が実行している Java と同じものを実行していることを確認します。インストーラーを利用した場合、<application-home>/jre/java を利用する必要があります。

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

   メール サーバーの場合は 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

To get more details from a failed connection, use the -Djavax.net.debug=ssl parameter. For example: 

java -Djavax.net.debug=ssl SSLPoke jira.example.com 443

接続に成功すると、以下のように表示されます。

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

JVM 引数に -Djavax.net.ssl.trustStore が存在する場合、Java はデフォルト (cacerts) ではなく、設定されたトラストストアを使用します。-Djavax.net.ssl.trustStore パラメーターが問題を引き起こしているかどうかは、カスタム トラストストアを使用してSSLPoke を実行するのと同じ JVM 引数を使用してSSLPoke テストを実行することで確認できます。次に例を示します。

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

これに失敗する (トラストストアに適切な証明書が含まれていないことが確認された) 場合、「SSL サービスへの接続」の手順に従い、定義したカスタム トラストストアに証明書をインポートする必要があります。

原因

Java は SSL (例: HTTPS、IMAPS、LDAPS) 経由で他のアプリケーションに接続しようとするときに、信頼できるアプリケーションにのみ 接続できます。Java において信頼のやりとりは、トラストストアを持って行います (通常 $JAVA_HOME/lib/security/cacerts)。これは既知のすべての認証局 (CA) 証明書の一覧を含み、Java はこれらの CA のいずれかによって署名された証明書、またはそのキーストア内にある公開証明書のみを信頼します。たとえば、アトラシアン証明書を見ると、*.atlassian.com であることがわかります。証明書は、中間証明書である DigiCert High Assurance EV Root CA と DigiCert High Assurance CA-3 によって署名されています。これらの中間証明書は Entrust.net Secure Server CA のルート証明書で署名されています。

これらの 3 つの証明書の組み合わせは証明書チェーンと呼ばれます。これらはすべて Java トラストストア (cacerts) 内にあるため、Java はこれらによって署名されたすべての証明書 (この場合は *.atlassian.com) を信頼します。あるいは、*. atlassian.com 証明書がトラストストア内にある場合、Java はそのサイトも信用します。

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

For details on how to examine a website's certificate chain, see the section, View a certificate, in Secure Website Certificate.

ソリューション

1. ターゲット インスタンスの公開証明書が、「SSL サービスへの接続」の手順に従って、トラストストアにインポートされていることを確認します。
2. JRE/JDK が複数ある場合があるため、証明書が正しいトラストストアにインポートされていることを確認します。「JVM にパブリック SSL 証明書をインポートする方法」を参照してください。
3. 適切なトラストストアが使用中であることを確認します。-Djavax.net.ssl.trustStore が設定されている場合、デフォルトのトラストストアの場所が上書きされるため、確認が必要です。
4. このエラーが LDAP サーバーを LDAPS 経由で連携させるときに発生していて、複数の LDAP サーバーが存在する場合、LDAP ユーザー ディレクトリ構成の [Follow referrals] オプションの選択を解除します。詳細については「LDAP ディレクトリへの接続」をご確認ください。あるいは、他の LDAP サーバーの SSL 証明書を Confluence のトラストストアにインポートします。
5. アンチウイルス ツールの「SSL スキャン」によって SSL/TLS がブロックされているかどうかを確認します。ブロックされていたら、この機能を無効化するか、ターゲット アドレスを除外するように設定します (方法については製品マニュアルをご確認ください)。
6. Exchange などのメール サーバーに接続する場合、認証情報としてプレーン テキストが許可されていることを確認します。
7. ターゲット サーバーが SSL を適切に提供するように構成されていることを確認します。これは SSL サーバー テスト ツールで行えます。
8. これらすべてに失敗する場合、ご利用のトラストストアが古くなっている可能性がああります。ご利用のアプリケーションでサポートされている最新のバージョンに Jira をアップグレードしてください。

SSL Poke の詳細

アトラシアンの SSL Poke のソース コードはこちらで確認できます。

SSL Poke のフォーク バージョンはコミュニティで提供されています。ここでは Java 11 やプロキシなどの追加の機能がサポートされます。

次のような良い例があります。

• https://github.com/gebi/sslpoke
• https://gist.github.com/bric3/4ac8d5184fdc80c869c70444e591d3de