SSL と Apache を使用してアトラシアン アプリケーションを保護する

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

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Fisheye および Crucible は除く

アトラシアンの製品はSSLに対応しています。しかし、アトラシアンのサポートはその設定に対して支援は行いません。つまり、アトラシアンではこれらに関するあらゆるサポートの提供が保証されません

設定に関してサポートが必要であれば、Atlassian Answers に質問をあげてください。


このページでは、Apache をリバース プロキシとして使用する場合に HTTPS (HTTP over SSL) を構成する方法について説明します。インターネット経由のアプリケーション アクセスで、ユーザー名、パスワード、およびその他の匿名データを暗号化したいときにこの方法を検討することをおすすめします。

このページの手順は、アトラシアンの次のサーバー アプリケーションに適用されます。 

  • Jira Server アプリケーション (Jira Software Server、Jira Core、Jira Service Desk)
  • Confluence Server
  • Bamboo Server
  • Bitbucket Server
  • Fisheye
  • Crucible
  • Crowd

In the examples that follow on this page, <atlassianapp> refers to the name of any of the Atlassian server applications above.

Prerequisites

次の条件を満たしている必要があります。

有効な認証局の SSL 証明書

SSL 証明書は、訪問者の web ブラウザと自身のサーバーとの間の通信を暗号化するために使用される、一連のファイルです。ご利用の web サイトのアイデンティティを証明するためにも役立ちます。自己署名証明書ではなく、認証局 (CA) が発行および署名した SSL 証明書を使用することをおすすめします。

CA が発行した証明書を使用することの主なメリットは、訪問者や web サイトに接続している他のアプリケーションが、サイトのアイデンティティをエラーなしで検証できることです。CA が発行していない SSL 証明書を使用していると接続エラーが発生する場合があるため、これは、アトラシアン アプリケーション間でアプリケーション リンクを構成している場合など、自身のアプリケーションが他のアプリケーションとやり取りしているときに特に重要です。

アトラシアン アプリケーションが Apache リバース プロキシの背後で実行されている

HTTP でリバース プロキシ経由でアプリケーションに接続する」のステップを完了していることを確認して続行します。ゼロから開始する場合、標準の HTTP でリバース プロキシが動作することを確認してから、SSL 構成を別個のステップとして扱うことをおすすめします。

パート A. アトラシアン アプリケーションを設定する

このセクションでは、各アトラシアン アプリケーションに組み込まれた Tomcat (Fisheye または Crucible の場合は Jetty) web サーバーのプロキシ構成を、SSL が有効化されたリバース プロキシの背後で実行するために更新する方法について説明します。

1. アトラシアン アプリケーションを停止する

アプリケーションを停止すると、Tomcat も停止します。

 

クリックして停止についての情報を表示...
Jira アプリケーション

次のコマンドを Jira のインストール ディレクトリで実行します。

  • bin/start-jira.sh
  • bin/stop-jira.sh

Windows の場合、次のコマンドを実行します。

  • bin\start-jira.bat
  • bin\stop-jira.bat

Jira アプリケーションの起動および終了スクリプト」もご参照ください。

Confluence

次のコマンドを Confluence のインストール ディレクトリで実行します。

  • bin/start-confluence.sh
  • bin/stop-confluence.sh

Windows の場合、次のコマンドを実行します。

  • bin\start-confluence.bat
  • bin\stop-confluence.bat

システム起動時に Confluence を自動的に開始する 」もご参照ください。

Bamboo Server

次のコマンドを Bamboo のインストール ディレクトリで実行します。

  • bin/start-bamboo.sh
  • bin/stop-bamboo.sh

Windows の場合、次のコマンドを実行します。

  • bin\start-bamboo.bat
  • bin\stop-bamboo.bat

Bamboo をサービスとして実行する」もご参照ください。

Bitbucket Server

See Start and stop Bitbucket.

Fisheye

次のコマンドを Fisheye のインストール ディレクトリで実行します。

  • bin/start.sh
  • bin/stop.sh

Windows の場合、次のコマンドを実行します。

  • bin\start.bat
  • bin\stop.bat

Fisheye を Windows サービスとして実行する」もご参照ください。

Crucible

次のコマンドを Crucible のインストール ディレクトリで実行します。

  • bin/start.sh
  • bin/stop.sh

Windows の場合、次のコマンドを実行します。

  • bin\start.bat
  • bin\stop.bat

Crucible を Windows サービスとして実行する」もご参照ください。

Crowd

次のコマンドを Crowd のインストール ディレクトリで実行します。

  • /start_crowd.sh
  • /stop_crowd.sh

Windows の場合、次のコマンドを実行します。

  • \start-crowd.bat
  • \stop-crowd.bat

Crowd を Windows サービスとしてインストールする」もご参照ください。

2. Connector 構成を更新する

Bitbucket Server 5.0 を構成している場合

Bitbucket Server 5.0 以降では Tomcat のコネクタを直接設定することができません。このため、このセクションの設定は、Bitbucket Server 4.14 以前でのみ利用できます。

server.xml 構成は <Bitbucket home directory>/shared/bitbucket.properties で置き換えられています。

対応するプロパティと、以降の設定に対応する手順については、「server.xml のカスタマイズを bitbucket.properties に移行する」をご参照ください。bitbucket.properties へのマッピングが完了したら、「パート B: SSL を構成する」に進んでください。

FishEye または Crucible を使用している場合、管理領域からプロキシ ホスト、プロキシ スキーム、およびプロキシ ポートを設定します。詳細については、「Fisheye web サーバーを設定する」を参照してください。

その他のいずれかアトラシアン サーバー アプリケーションのいずれかを使用している場合、Connector ディレクティブを次のように設定します。注: mod_proxy_ajp を使用してリバース プロキシをセットアップしている場合、このステップをスキップして以降のパート B に進んでかまいません。

各アプリケーションにおいて、Tomcat の server.xml  ファイルで通常の (非 SSL) Connector ディレクティブを見つけ、次のように Connector ディレクティブで scheme および proxyPort 属性を更新します。これらの属性はリバース プロキシの構成時に追加済みであることを想定しています。次のように、scheme を "https" に、proxyPort を Apache が SSL をリッスンしているポートに (例: "443") 変更する必要があります。

<Connector port=<default>
	maxThreads=<default>
    minSpareThreads=<default>
    connectionTimeout=<default>
    enableLookups=<default>
    maxHttpHeaderSize=<default>
    protocol=<default>
    useBodyEncodingForURI=<default>
    redirectPort=<default>
    acceptCount=<default>
    disableUploadTimeout=<default>
	proxyName="<subdomain>.<domain>.com"
	proxyPort="443"
    secure="true"
	scheme="https"/>

For more information about configuring the Tomcat Connector, refer to the Apache Tomcat 8.0 HTTP Connector Reference.

パート B: SSL を構成する

1. 環境を準備する

SSL 証明書ファイルをサーバーにコピー

一般的な SSL 証明書は次のようないくつかのファイルで構成されます。

  • 証明書ファイル
    • 証明書ファイルは SSL 証明書の公開部分であり、接続相手が参照可能です。自身の証明書ファイルのみが復号化できるようにデータを暗号化する方法をクライアントに伝えます。クライアントに対してなりすましの危険性がないことを証明するため、証明書ファイルには自身のサイトのアイデンティティと、証明書を発行した認証局 (CA) についての情報も含まれます。
  • 証明書キー ファイル
    • 証明書キー ファイルは、SSL 証明書の非公開部分です。証明書ファイルには、自身の公開済みの証明書を使用してデータを暗号化したクライアントから受け取ったデータを復号化するために必要な情報が含まれます。これがないと、証明書ファイルで暗号化したデータを読み取ることができないため、第三者が公開証明書を使用して自身になりすますことはできません。
  • 証明書 チェーン ファイル (任意)
    • 証明書ファイルがサイトのアイデンティティを証明することと同様に、証明書キー ファイルは CA のアイデンティティを証明します。接続先のクライアントが認識しない CA によって SSL 証明書が発行されていた場合、クライアントは証明書チェーン ファイルで CA のアイデンティティを、それによってサイトのアイデンティティを確認します。これは厳密には必須ではありませんが、証明書チェーン ファイルにより、多数のクライアントへの互換性を持つ SSL 構成を実現できます。

これらのファイルはサーバー内で Apache が到達可能な任意の場所にコピーし、所有者を root ユーザーに設定する必要があります。自己署名証明書を使用することもできますが、本番環境での自己署名証明書の使用は推奨されません。

Apache SSL モジュールの有効化

SSL サポートを Apache で有効化してから SSL 証明書を構成します。

Debian / Ubuntu での手順を展開して確認

Ubuntu および Debian システムでは、SSL モジュールは既定でインストールされています。

次のコマンドで SSL モジュールを有効化します。

sudo a2enmod ssl
Fedora / CentOS での手順を展開して確認

Fedora および Centos システムでは、SSL モジュールのインストールが必要な場合があります。

次のコマンドで SSL モジュールをインストールします。

sudo yum install mod_ssl

mod_ssl をインストールすると、モジュールが自動的に有効化されます。

Windows / その他の OS での手順を展開して確認

http.conf ファイルを見つけて編集し、次の行を追加またはコメント解除します。

LoadModule ssl_module modules/mod_ssl.so

2. VirtualHost 構成を更新する

現在の VirtualHost のリバース プロキシ構成は次のように設定されていることを想定しています。

<VirtualHost *:80>
    ServerName <subdomain>.<domain>.com
     
    ProxyRequests Off
    
    <Proxy *>
         Require all granted
    </Proxy>
 
    ProxyPass /<contextpath> http://<domain>:<port>/<contextpath>
    ProxyPassReverse /<contextpath> http://<domain>:<port>/<contextpath>
</VirtualHost>

リバース プロキシ構成で mod_proxy_http ではなく mod_proxy_ajp を使用している場合、上記のプロキシ URL の例は http:// ではなく ajp:// で開始されます。SSL をサポートする VirtualHost 構成の更新手順は、いずれのプロキシ タイプでも同じです。

Confluence 6.0.x 以降では共同編集のため、AJproxy 接続はサポートされません。

リッスン ポートの変更

既存の VirtualHost 構成を変更して、HTTP 接続ではなく HTTPS 接続をリッスンするようにする必要があります。VirtualHost のリッスン ポートを HTTPS をリッスンするポート (既定は 443) に変更するための最初のステップは、次のとおりです。

<VirtualHost *:443>
    ...
</VirtualHost>

SSL 証明書の追加

VirtualHost の内部で SSL を有効化して証明書ファイルを添付するため、VirtualHost 構成の末尾に次の行を追加します。

<VirtualHost *:443>
    ...
 
    SSLEngine On
    SSLCertificateFile /path/to/your/cert.pem
    SSLCertificateKeyFile /path/to/your/privkey.pem
    SSLCertificateChainFile /path/to/your/chain.pem
</VirtualHost>

HTTP を HTTPS にリダイレクト

サーバーへの安全な接続を強制するため、HTTP を HTTPS にリダイレクトすることをおすすめします。これを行うには、元の HTTP ポートをリッスンする新しい VirtualHost を追加します。

<VirtualHost *:80>
    ServerName <subdomain>.<domain>.com
    Redirect Permanent /<contextpath> https://<subdomain>.<domain>.com/<contextpath>
</VirtualHost>


完全な VirtualHost 構成は次のようになります。

<VirtualHost *:443>
    ServerName <subdomain>.<domain>.com
     
    ProxyRequests Off
    
    <Proxy *>
         Require all granted
    </Proxy>
 
    ProxyPass /<contextpath> http://<domain>:<port>/<contextpath>
    ProxyPassReverse /<contextpath> http://<domain>:<port>/<contextpath>
 
    SSLEngine On
    SSLCertificateFile /path/to/your/cert.pem
    SSLCertificateKeyFile /path/to/your/privkey.pem
    SSLCertificateChainFile /path/to/your/chain.pem
</VirtualHost>
 
<VirtualHost *:80>
    ServerName <subdomain>.<domain>.com
    Redirect Permanent /<contextpath> https://<subdomain>.<domain>.com/<contextpath>
</VirtualHost>

Confluence 6.0 以降を Synchrony (共同編集に必要) と使用している場合、Apache 2.4 に加え、

次のディレクティブおよび Location ブロックを使用する必要があります (クリックして展開)
Use the following directives and location blocks in the virtual host block:
<VirtualHost *:443>
    ServerName <subdomain>.<domain>.com

    ProxyRequests Off

    <Proxy *>
        Require all granted
    </Proxy>
     
    SSLEngine On
    SSLCertificateFile /path/to/your/cert.pem
    SSLCertificateKeyFile /path/to/your/privkey.pem
    SSLCertificateChainFile /path/to/your/chain.pem

    ProxyPass /synchrony http://<domain>:8091/synchrony

    <Location /synchrony>
        Require all granted
        RewriteEngine on
        RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
        RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
        RewriteRule .* ws://<domain>:8091%{REQUEST_URI} [P]
    </Location>

 	ProxyPass /confluence http://<domain>:8090/confluence
    ProxyPassReverse /confluence http://<domain>:8090/confluence

    <Location /confluence>
        Require all granted
    </Location>

</VirtualHost>
 
<VirtualHost *:80>
    ServerName <subdomain>.<domain>.com
    Redirect Permanent /confluence  https://<subdomain>.<domain>.com/confluence
    Redirect Permanent /synchrony   https://<subdomain>.<domain>.com/synchrony
</VirtualHost>


仮想ホスト ブロック内の新しいディレクティブは次の機能を実行します。

特定の仮想ホスト用のディレクティブの構成
<VirtualHost *:443>

すべての IP アドレスと照合するためのワイルドカードとして文字 * を、既定の https ポートとして 443 を使用します。これにより、Apache では仮想ホストの ServerName 値でリクエストを照合します。

Apache 2.4 の VirtualHost ドキュメントをご参照ください。

SSL エンジンの有効化
SSLEngine On

このディレクティブは Apache に対し、対象の仮想ホストで SSL が使用されていることを伝えます。

Apache 2.4 の SSLEngine ドキュメントをご参照ください。

証明書ファイルの構成
SSLCertificateFile /path/to/cert.pem

これはディスク上の証明書ファイルへの完全なパスです。証明書ファイルへのパスにスペースが含まれる場合、パスをダブル クォーテーションで囲む必要があります。

Apache 2.4 の SSLCertificateFile ドキュメントをご参照ください。

証明書の非公開キー ファイルの構成
SSLCertificateKeyFile /path/to/privkey.pem

これはディスク上の非公開キー ファイルへの完全なパスです。非公開キー ファイルへのパスにスペースが含まれる場合、パスをダブル クォーテーションで囲む必要があります。

Apache 2.4 の SSLCertificateKeyFile ドキュメントをご参照ください。

証明書チェーン ファイルの構成
SSLCertificateChainFile /path/to/chain.pem

これはディスク上の非公開キー ファイルへの完全なパスです。この設定は任意ですが、ファイルが存在する場合は構成することをおすすめします。非公開キー ファイルへのパスにスペースが含まれる場合、パスをダブル クォーテーションで囲む必要があります。

Apache 2.4 の SSLCertificateChainFile ドキュメントをご参照ください。

HTTP を HTTPS にリダイレクト
Redirect permanent /<contextpath> https://<subdomain>.<domain>.com/<contextpath>

Redirect permanent ディレクティブはリソースへのすべてのアクセスに対し、宛先が新しい場所に永続的に移動されている旨を伝えます。このインスタンスでは Apache に接続する他のソフトウェアに対し、アプリケーションが http URL から新しい https URL に移動したことを伝えます。

Apache では Redirect permanent の代わりに mod_rewrite モジュールを使用して http から https へのリダイレクトを構成することもできます。ただし、Apache では Redirect が利用可能な場合はそれを mod_rewrite よりも優先的に使用することが推奨されています。

Apache 2.4 の、mod_rewrite を使用すべきでないタイミングについてのドキュメントをご参照ください。

3. Apache の既定の SSL 構成をオーバーライドする

Apache には既定でいくつかの追加構成ファイルが同梱されており、これには既定の SSL 構成が含まれます。VirtualHost の前に既定の SSL 構成が読み込まれた場合、クライアントへの証明書チェーンの提供で問題が発生する可能性があります。これにより、特定の状況下で、ブラウザではアプリケーションが SSL で動作しているように見えるが、他のアプリケーションは無効な構成を検出し、接続に失敗します。

既定の SSL 構成ファイルは /etc/httpd/conf.d/ssl.conf に格納されています。VirtualHost ディレクティブがこのディレクトリで独自の .conf  ファイルに格納されている場合、このディレクトリのファイルはアルファベット順で読み込まれるため、.conf  ファイルがアルファベット順で ssl.conf よりも前にくるようにします。

VirtualHost ディレクティブが /etc/httpd/conf/httpd.conf に直接書き込まれている場合、次の行を見つけ、これらが VirtualHost エントリの前ではなくあとに表示されるようにします。

# Supplemental configuration
#
# Load config files in the "/etc/httpd/conf.d" directory, if any.
IncludeOptional conf.d/*.conf

4. Apache を再起動する

Debian および Ubuntu

以下を使用して、コマンド ラインから Apache を再起動します。

$ sudo service apache2 restart

Fedora および CentOS

以下を使用して、コマンド ラインから Apache を再起動します。

$ sudo apachectl graceful

systemd を使用して Apache を再起動することもできます。CentOS の場合の例は次のようになります。

$ sudo systemctl restart httpd.service

Windows

Apache サービスを停止および開始するには、[コントロール パネル] > [管理ツール] > [サービス] に移動し、"Apache2" を見つけ、それを選択します。メニュー バーから停止ボタン (四角形) を選択し、サービスのステータスが [停止] になるまで待ちます。サービスが停止したら、開始ボタン (三角形) を選択し、ステータスが [開始] になるまで待ちます。

5. 各アトラシアン アプリケーションを再起動する

Now, restart each Atlassian application. See the "stopping and starting" instructions above. 

製品に新しい URL を使用してアクセス可能かどうかを確認します。

6. アプリケーションのベース URL を更新する

各アトラシアン アプリケーションでベース URL を更新し、http ではなく https プロトコルを使用するようにします (例:  https://www.example.com/<atlassianapp>)。

パート C. SSL 構成をテストする

SSL を構成するうえでもっとも重要なステップは、構成を徹底的にテストし、さまざまなブラウザやアプリケーションでの互換性を確認することです。SSL があるブラウザでは期待したとおりに動作するが、ほかのアプリケーションが接続すると失敗する場合があります。これにより、アプリケーションに接続するシステムで問題が発生する可能性があります。アプリケーションに接続する可能性があるものには、次のような例があります。

  • アプリケーション リンク
  • サードパーティ製のプラグイン
  • REST API を使用するスクリプトやツール
  • アプリケーション固有の機能 (Bamboo のリモート エージェント、Bitbucket Server の Smart Mirror サーバーなど)

このような問題は即座には検知されず、時間が経過してから検出された場合に原因の絞り込みが難しくなる場合があります。このため、SSL 構成はすぐにテストし、あとから検出および診断することが難しい構成の問題を修正しておくことが重要です。

次のようなテストを実行することをおすすめします。3 つのテストのうち 1 つのみが失敗する場合が多いため、すべてのテストを実行することが重要です。 

1. ブラウザ テスト

もっともシンプルなテストは、web ブラウザからアプリケーションにアクセスすることです。次の項目が実現されていることを確認します。

  • 非 HTTPS の URL (例: http://<subdomain>.<domain>.com) でアプリケーションにアクセスすると、https://<subdomain>.<domain>.com に自動的にリダイレクトされること
  • 警告やポップアップ ダイアログが表示されないこと
  • アドレス バーで web サイトのアドレスの横に鍵のアイコンが表示されること
  • 鍵のアイコンをクリックして [詳細] または [証明書を表示] をクリックすると、証明書が有効であることと、証明書を発行した CA が表示されること

2. SSLPoke

SSLPoke はアトラシアンが作成した、SSL の問題の診断を支援するためのシンプルな Java ユーティリティです。このテストはローカルの Java インストールの自身の信頼済み認証局ストアに依存するため、既存のアトラシアン アプリケーションをホストしているサーバーなどの、対象のアプリケーションに接続することを予定しているシステムから実行することをおすすめします。

The KB article Unable to connect to SSL services due to "PKIX Path Building Failed" error covers the steps to download and run the SSLPoke utility. When using SSLPoke from another server that needs to connect to your app, it's important to make sure the version of Java being used is the same one used by that server to run its applications.

3. OpenSSL

ほとんどの Unix ライクのシステムでは OpenSSL バイナリがインストール済みであり、このバイナリは Windows でも利用できます。OpenSSL テストは証明書と証明書チェーンの両方を検証するため、潜在的な検証の問題の特定に役立ちます。

OpenSSL テストを実行するには、次のコマンドを実行します。 

openssl s_client -connect <subdomain>.<domain>.com:443

このテストは証明書についての多数の情報を返します。成功すると、出力の最後の行は次のようになります。 

Verify return code: 0 (ok)
---

上記のテストを終えたら、これで完了です。

混合コンテンツについて

ブラウザが HTTPS の URL からコンテンツを読み込んだ際にブラウザに非 HTTPS コンテンツが含まれていると、セキュリティ上の理由により、ブラウザは非 HTTPS コンテンツをブロックします。これは混合コンテンツのブロックとして知られています。アプリケーションに接続する他のアトラシアン アプリケーションがある場合、一部の連携機能ではリモート アプリからのコンテンツの読み込みが必要であるため、すべてのアプリを HTTPS で実行するようにセットアップすることをおすすめします。


説明

このページでは、Apache をリバース プロキシとして使用する場合に HTTPS (HTTP over SSL) を構成する方法について説明します。インターネット経由のアプリケーション アクセスで、ユーザー名、パスワード、およびその他の匿名データを暗号化したいときにこの方法を検討することをおすすめします。

製品Jira, Confluence, Bamboo, Bitbucket, Fisheye, Crucible, Crowd
プラットフォーム

Server、Data Center

Last modified on Mar 15, 2021

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.