31.6 SSLをサポートするセキュアWebサーバのセットアップ

クレジットカード情報などの機密データをWebサーバやクライアント間で送信する場合は必ず、認証を使用して、安全で、暗号化された接続の確立を推奨します。mod_sslは、クライアントとWebサーバ間のHTTP通信にセキュアソケットレイヤ(SSL)プロトコルとトランスポートレイヤセキュリティ(TLS)プロトコルを使用して、強力な暗号化を行います。SSL/TSLを使用することにより、Webサーバとクライアント間でプライベートな接続が確立されます。データの整合性が保証され、クライアントとサーバ間で相互認証ができるようになります。

この目的で、サーバは、URLに対するリクエストに応答する前に、サーバの有効な識別情報を含むSSL証明書を送ります。これにより、サーバが唯一の正当な通信相手であることが保証されます。加えて、この証明書は、クライアントとサーバの間の暗号化された通信が、重要な内容がプレーンテキストとして見られる危険なしに、情報を転送できることを保証します。

mod_sslは、SSL/TSLプロトコル自体は実装しませんが、ApacheとSSLライブラリ間のインタフェースとして機能します。SUSE Linux Enterprise Serverでは、OpenSSLライブラリが使用されます。OpenSSLは、Apacheとともに自動的にインストールされます。

メモ: TLS 1.0より後のTLSバージョン

OpenSSLライブラリは、TLS 1.0までのTLSバージョンをサポートしていますが、TLS 1.1や1.2などの新しいバージョンはサポートしていません。apache2-mod_nssパッケージのmod_nssは、Mozilla Network Security Servicesライブラリを使用してTLS 1.1と1.2を提供しています。詳細については、セクション 31.7, NSSをサポートするセキュアWebサーバのセットアップを参照してください。

Apacheでmod_sslを使用した場合の最も明白な効果は、URLのプレフィックスがhttp://ではなくhttps://となることです。

ヒント: 証明書サンプル

パッケージapache2-example-certificatesをインストールすると、架空会社Snake Oilの証明書のサンプルを入手できます。

31.6.1 SSL証明書の作成

SSL/TSLをWebサーバで使用するには、SSL証明書を作成する必要があります。この証明書は、両者が互いに相手を識別できるように、Webサーバとクライアント間の認証に必要です。証明書の整合性を確認するには、すべてのユーザが信用する者によって署名される必要があります。

3種類の証明書を作成することができます。テストの目的のみのダミー証明書、あらかじめ定義されている信用する一部のユーザグループ用の自己署名付き証明書、および公的な独立団体のCA (Certificate Authority)によって署名される証明書です。

証明書の作成には、基本的に2つのステップで行うことができます。はじめに、CAの秘密鍵が生成され、次に、この鍵を使用してサーバ証明書が署名されます。

ヒント: 詳細情報

SSL/TSLの概念および定義の詳細については、http://httpd.apache.org/docs/2.2/ssl/ssl_intro.htmlを参照してください。

ダミー証明書の作成

ダミー証明書の生成は簡単です。/usr/bin/gensslcertスクリプトを呼び出すだけです。次のファイルを作成または上書きします。gensslcertのオプションのスイッチを使用して、証明書を微調整します。詳細は、/usr/bin/gensslcert -hを呼び出してください。

  • /etc/apache2/ssl.crt/ca.crt

  • /etc/apache2/ssl.crt/server.crt

  • /etc/apache2/ssl.key/server.key

  • /etc/apache2/ssl.csr/server.csr

  • /root/.mkcert.cfg

ca.crtのコピーは、ダウンロード用に/srv/www/htdocs/CA.crtにも配置されます。

重要: テスト専用

ダミー証明書は、実働システム上では使用しないでください。テストの目的のみで使用してください。

自己署名付き証明書の作成

イントラネットまたは定義されている一部のユーザグループ用にセキュアWebサーバをセットアップするとき、独自のCA (Certificate Authority)を通じて証明書に署名するので\'8f\'5c分な場合があります。

自己署名付き証明書の作成手順は、対話形式の9つのステップで構成されています。/usr/share/doc/packages/apache2ディレクトリに移動し、次のコマンドを実行します。/mkcert.sh make --no-print-directory /usr/bin/openssl /usr/sbin/ customこのディレクトリ以外からこのコマンドを実行しないでください。プログラムは、一連のプロンプトを表示します。この一部には、ユーザ入力が必要なものもあります。

mkcert.shを使用した自己署名付き証明書の作成

  1. 証明書を使用してシグネチャアルゴリズムを決定します

    一部の古いブラウザでDSAを使用すると問題があるため、RSA (デフォルトのR)を選択します。

  2. CA用RSA秘密鍵を生成(1024ビット)

    操作の必要はありません。

  3. CAへのX.509証明書署名要求を生成

    ここで、CAの識別名を作成します。このとき、国名または組織名など、いくつかの質問に答える必要があります。ここで入力した内容が証明書に含まれるため、有効なデータを入力します。すべての質問に答える必要はありません。該当しない、または空白のままにする場合は、.を使用します。一般名は、CA自体の名前です。My company CAなど、意味のある名前を選択します。

    重要: CAの一般名

    CAの一般名はサーバの一般名と異なる名前にする必要があるため、この手順では完全修飾ホスト名は選択しないでください。

  4. CAによる署名用のX.509証明書を生成

    証明書バージョン3を選択します(デフォルト)。

  5. SERVER用のRSA秘密鍵を生成(1024ビット)

    操作の必要はありません。

  6. SERVERへのX.509証明書署名要求を生成

    ここで、サーバの鍵の識別名を作成します。質問は、CAの識別名で答えたものとほぼ同じです。ここで入力するデータがWebサーバに適用されますが、CAのデータと同一である必要はありません(サーバが別の場所に位置する場合など)。

    重要: 一般名の選択

    ここで入力する一般名は、セキュアサーバの完全修飾ホスト名(www.example.comなど)である必要があります。完全修飾ホスト名でない場合、Webサーバへのアクセス時、証明書がサーバと一致していないという警告がブラウザに表示されます。

  7. 独自のCAによる署名付きX.509証明書を生成

    証明書バージョン3を選択します(デフォルト)。

  8. セキュリティ用パスフレーズのあるCAのRSA秘密鍵の暗号化

    CAの秘密鍵をパスワードで暗号化することをお勧めします。そのため、Yを選択し、パスワードを入力します。

  9. セキュリティ用パスフレーズのあるSERVERのRSA秘密鍵の暗号化

    秘密鍵をパスワードで暗号化すると、Webサーバを起動するたびにこのパスワードを入力するよう求められます。このため、Webサーバのブートおよび再起動時にサーバを自動的に起動するのが難しくなります。したがって、一般的に、この質問にはNと答えます。パスワードで暗号化しないと鍵は保護されないため、この鍵へのアクセスは許可されたユーザのみに限定する必要があることに注意してください。

    重要: サーバ鍵の暗号化

    サーバ鍵をパスワードで暗号化する場合は、/etc/sysconfig/apache2APACHE_TIMEOUTの値を増やします。値を増やさないと、サーバを起動しようとする試みが停止する前に、パスフレーズを入力するのに十分な時間がなくなります。

スクリプトの結果ページに、生成された鍵と証明書のリストが表示されます。スクリプトの出力とは異なり、ファイルはローカルディレクトリのconf内ではなく、適切な場所である、/etc/apache2/内に生成されます。

最後のステップとして、Webブラウザ内の認識および信用されたCAのリストに含まれるように、ユーザがアクセスできる場所に/etc/apache2/ssl.crt/ca.crtからCA証明書ファイルをコピーします。コピーしない場合、ブラウザは、この証明書が不明な認証局から発行されたものであると見なします。証明書は1年間有効です。

重要: 自己署名付き証明書

自己署名付き証明書は、CA (Certificate Authority)として認識および信用するユーザによってアクセスされるWebサーバ上でのみ使用します。自己署名付き証明書をパブリックショップなどで使用することはお勧めしません。

公式に署名された証明書の取得

証明書に署名する公式なCA (Certificate Authority)は、多数存在します。証明書は、信用のあるサードパーティによって署名されるため、完全に信用できます。通常、一般に運営されているセキュアWebサーバでは、証明書が公式に署名されます。

最も良く知られている公式なCAには、Thawte (http://www.thawte.com/)またはVerisign (http://www.verisign.com)があります。これらや、その他のCAは、すべてのブラウザにすでにコンパイルされているため、これらのCAによって署名された証明書は、ブラウザによって自動的に許可されます。

公式に署名された証明書を要求するとき、CAに証明書を送信しません。代わりに、CSR (Certificate Signing Request)を発行します。CSRを作成するには、/usr/share/ssl/misc/CA.sh -newreqスクリプトを呼び出します。

はじめに、スクリプトは、CSRの暗号化に使用されているパスワードを問い合わせてきます。その後、識別名を入力するよう求められます。このとき、国名または組織名など、いくつかの質問に答える必要があります。ここで入力した内容が証明書に含まれ、確認されるため、有効なデータを入力します。すべての質問に答える必要はありません。該当しない、または空白のままにする場合は、.を使用します。一般名は、CA自体の名前です。My company CAなど、意味のある名前を選択します。最後に、チャレンジパスワードおよび代替の企業名を入力する必要があります。

スクリプトを呼び出したディレクトリでCSRを検索します。ファイルには、newreq.pemという名前が付きます。

31.6.2 SSLサポートのあるApacheの設定

Webサーバ側のSSLとTLS要求用のデフォルトのポートは 443です。ポート 80をリスンする通常のApacheと、ポート 443をリスンするSSL/TL対応のApacheとの間に競合は生じません。通常、ポート80とポート443への要求はそれぞれ別の仮想ホストが処理し、別の仮想サーバに送られます。

重要: ファイアウォール設定

ポート443でSSL対応のApache用のファイアウォールを開くことを忘れないでください。ファイアウォールは、“Configuring the Firewall with YaST” (Chapter “Masquerading and Firewalls”, ↑Security Guide)で説明されているように、YaSTを使用して設定できます。

SSLモジュールはグローバルサーバ設定でデフォルトで有効になっています。ホストで無効にされている場合は、コマンドa2enmod sslで有効にします。最終的にSSLを有効にするには、サーバをフラグSSLで起動する必要があります。このためには、a2enflag SSLを呼び出します。サーバ証明書をパスワードで暗号化している場合は、/etc/sysconfig/apache2APACHE_TIMEOUTの値を増やし、Apacheの起動時にパスフレーズを入力するのに十分な時間が与えられるようにします。これらの変更を適用するため、サーバを再起動します。再ロードでは不十分です。

仮想ホスト設定ディレクトリには、SSL固有ディレクティブが詳細に記述されている/etc/apache2/vhosts.d/vhost-ssl.templateテンプレートが含まれています。一般的な仮想ホスト設定については、仮想ホスト設定を参照してください。

始めるには、テンプレートを/etc/apache2/vhosts.d/mySSL-host.confにコピーして編集します。次のディレクティブの値を調整するだけです。

  • DocumentRoot

  • ServerName

  • ServerAdmin

  • ErrorLog

  • TransferLog

名前ベースの仮想ホストとSSL

IPアドレスが1つだけのサーバで、複数のSSL対応の仮想ホストを実行することはできません。名前ベースの仮想ホスティングでは、要求されたサーバ名をApacheが知っている必要があります。SSL接続の問題は、SSL接続が(デフォルトの仮想ホストの使用により)確立された後でのみ、そのような要求の読み込みが可能なことです。その結果、証明書がサーバ名に一致しないという警告メッセージが表示されます。

SUSE Linux Enterprise Serverは、SNI (Server Name Indication)と呼ばれるSSLプロトコルの拡張を組み込んでおり、仮想ドメインの名前をSSLネゴシエーションの一部として送信することで、この問題を解決します。これにより、サーバが正しい仮想ドメインに早く切り替わり、ブラウザに正しい証明書を提示することが可能になります。

SUSE Linux Enterprise Serverでは、SNIはデフォルトで有効になっています。名前ベースの仮想ホストをSSLで使用可能にするには、名前ベースの仮想ホストで説明されているようにサーバを設定します (ただし、SSLでは、ポート80ではなく、ポート443を使用)。

重要: SNIブラウザのサポート

SNIは、クライアント側でもサポートされる必要があります。SNIは、ほとんどのブラウザでサポートされていますが、モバイルハードウェアの一部のブラウザやWindows* XP上のInternet ExplorerとSafariにはSNIのサポートがありません。詳細については、http://en.wikipedia.org/wiki/Server_Name_Indicationを参照してください。

ディレクティブSSLStrictSNIVHostCheckを使用して、SNIに非対応のブラウザを処理する方法を設定しますSNI非対応ブラウザは、サーバ設定でonに設定されると、すべての仮想ホストに関して拒否されます。VirtualHostディレクティブ内でonに設定されると、この特定のホストへのアクセスが拒否されます。

サーバ設定でoffに設定されると、サーバはSNIサポートがないかのように動作します。SSL要求は、(ポート443に対して)定義された最初の仮想ホストによって処理されます。