SSL サービスに接続する
アトラシアンの製品はSSLに対応しています。しかし、アトラシアンのサポートはその設定に対して支援は行いません。したがって、アトラシアンは、そのためのサポートの提供を保証できません 。
- SSL証明書の変更に際してサポートが必要であれば、証明書の提供元のベンダーに相談してください。
- 設定に関してサポートが必要であれば、Atlassian Answers に質問をあげてください。
本ページでは、JIRA、Confluence等のウェブアプリケーションを SSL ラッピングされた多種プロトコル経由の SSL 上で外部サーバーに接続して取得する手順について説明します。 SSL サービスは以下の作業を実行する場合に必要です。
- Confluence マクロで
https://...
URL を参照する。 - IMAPS サーバーを使用して JIRA でメールを取得する。
- SMTP over SSL (SSL) を使用して JIRA でメールを送信する。
- SSL 上で LDAP ディレクトリに接続する。
- SSL 上で Trusted Applications を設定する。
If you want to run JIRA itself over SSL, see Running JIRA over SSL or HTTPS or Integrating JIRA with Apache using SSL.
自動的にSSL証明書を追加します!
We now have a JIRA SSL Atlassian Labs plugin for this process. Please install and use the plugin before going through these docs.
問題症状が発生した場合
SSL で暗号化された URL (HTTPS、LDAPS、IMAPS など) にアクセスしようとすると、例外をスローし、JIRA が接続を拒否する。例:
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 com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:441)
at javax.mail.Service.connect(Service.java:233)
at javax.mail.Service.connect(Service.java:134)
これは自己署名で暗号化されたページにアクセスする際に Chrome で発生する以下のエラーと同じですが、Java は「とにかく続行」することができないため、証明書を拒否します。
原因
Whenever JIRA 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 (this is what JIRA is written in) is that you have a keystore (typically $JAVA_HOME/lib/security/cacerts
) or also known as the trust store. This contains a list of all the known CA certificates and Java will only trust certificates that are signed by those CA certificate or public certificates that exist within that keystore. For example, if we look at the certificate for Atlassian:
We can see 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. Those three certificates combined are referred to as the certificate chain. As all of those CA certificates are within the Java keystore (cacerts
), Java will trust any certificates signed by them (in this case, *.atlassian.com). Alternatively, if the *.atlassian.com certificate was in the keystore, Java would also trust that site.
この問題は、自己署名 (認証局の署名がない) がされた証明書、または Java キーストアに存在しない証明書チェーンから発生します。問題が発生すると、JIRA は証明書を信用しなくなるため、アプリケーション接続が出来なくなります。
ソリューション
In order to resolve this, the public certificate need to be imported in the Java keystore that JIRA uses. In the example above, this is *.atlassian.com and we cover how to install it below.
お客様のサーバーに Portecle をインストールすることができない場合や、コマンドラインの利用をご希望の場合は、このページ下部にある コマンドラインを使用したインストール セクションをご覧ください。
サーバーの公開証明書を取得、インポートする
- Download and install the Portecle app onto the server that runs JIRA.
This is a third-party application and not supported by Atlassian.
Ensure the
<JAVA_HOME>
variable is pointing to the same version of Java that JIRA uses. See our Setting JAVA_HOME docs for further information on this.If running on a Linux/UNIX server, X11 will need to be forwarded when connecting to the server (so you can use the GUI), as below:
ssh -X user@server
- [Examine] メニューを選択し、[ Examine SSL/TLS Connection ] をクリックします。
- ターゲットとなるシステムの SSL ホストとポートを入力します。
- 読み込みが完了されるまで待ちます。完了したら、パブリック証明書を選択し、PEM をクリックします。
- 証明書をエクスポートし、保存します。
- Go back to the main screen and select the Open an existing keystore from disk option, select
cacerts
(for example$JAVA_HOME/lib/security/cacerts
) then enter the password (the default ischangeit
). - [Import a trusted certificate into the loaded keystore] ボタンを選択します。
- ステップ 6 で保存した証明書を選択し、適切なエイリアス (例: confluence) を付与して、信頼済みであることを確認します。
- 次のようなエラーが表示される可能性があります。
- これが発生した場合、[OK] をクリックして証明書を信頼済みとして許可します。
- 次のようなエラーが表示される可能性があります。
- キーストアをディスクに保存します。
- Jira を再起動します。
- ホストに接続できることをテストします。
コマンド ラインを使用したインストール
Fetch the certificate, replacing google.com with the FQDN of the server JIRA is attempting to connect to:
Unix:openssl s_client -connect google.com:443 < /dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > public.crt
Windows の場合:
openssl s_client -connect google.com:443 < NUL | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > public.crt
The command above will only be executed if you have Sed for Windowsas well as OpenSSL installed on your environment. If you don't have Sed or OpenSSL or you don't want to install it, use the instructions below as an alternative. Issue the following command:
openssl s_client -connect google.com:443
Save the output to a file called
public.cert.
Edit the thepublic.cert
file so it contains only what is between theBEGIN CERTIFCATE
andEND CERTIFICATE
lines. This is how your file should look like after you edited it:-----BEGIN CERTIFICATE----- < Certificate content as fetched by the command line. Don't change this content, only remove what is before and after the BEGIN CERTIFICATE and END CERTIFICATE. That's what your Sed command is doing for you :-) > -----END CERTIFICATE-----
証明書をインポートします。
The value of
<JAVA_HOME>
can be found either via thejava.home
propertly under Administration > System Settings or in the path used by the Java process in the output ofps -ef | grep java
.<JAVA_HOME>/bin/keytool -import -alias <server_name> -keystore <JAVA_HOME>/jre/lib/security/cacerts -file public.crt
The Application must be restarted after importing the certificate.
他のキーストアの場所
Java will normally use a system-wide keystore in $JAVA_HOME/jre/lib/security/cacerts
, but it is possible to use a different keystore by specifying a parameter, -Djavax.net.ssl.trustStore=/path/to/keystore, where '/path/to/keystore' is the absolute file path of the alternative keystore.
However, setting this is not recommended because if Java is told to use a custom keystore (eg. containing a self-signed certificate), then Java will not have access to the root certificates of signing authorities found in $JAVA_HOME/jre/lib/security/cacerts
, and accessing most CA-signed SSL sites will fail. It is better to add new certificates (eg. self-signed) to the system-wide keystore (as above).
デバッグ
次のような問題が発生する場合があります。
- 証明書が正しくないキーストアにインストールされている。
- The keystore does not contain the certificate of the SSL service you're connecting to or it contains the certificate of the SSL service but with the incorrect alias name.