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

このページでは、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.

前提条件

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

有効な認証局の SSL 証明書

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

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

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

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

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

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

2. Connector 構成を更新する

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"/>

Tomcat Connector の設定の詳細については、「Apache Tomcat 8.0 HTTP Connector リファレンス」を参照してください。

パート B: SSL を構成する

1. 環境を準備する

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

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

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

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

Apache SSL モジュールの有効化

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

sudo a2enmod ssl

sudo yum install mod_ssl

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 構成の更新手順は、いずれのプロキシ タイプでも同じです。

リッスン ポートの変更

既存の 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 に加え、

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 で実行するようにセットアップすることをおすすめします。