メニュー
Amazon Elastic Compute Cloud
Linux インスタンス用ユーザーガイド

チュートリアル: Amazon Linux で SSL/TLS を使用できるように Apache ウェブサーバーを設定する

Secure Sockets Layer/Transport Layer Security (SSL/TLS) は、ウェブサーバーとウェブクライアントの間に、転送中のデータが傍受されないように保護する、暗号化されたチャネルを確立します。このチュートリアルでは、Apache ウェブサーバーを実行している単一の Amazon Linux インスタンスに、SSL/TLS のサポートを手動で追加する方法を説明します。ここでは説明しませんが、AWS Certificate Manager は、商業グレードのサービスを提供する予定がある場合には良い選択肢です。

注記

歴史的経緯から、ウェブの暗号化は、単純に SSL と呼ばれることが少なくありません。ウェブブラウザでは今でも SSL がサポートされていますが、後継プロトコルである TLS プロトコルの方が攻撃を受けにくいと考えられています。Amazon Linux では、すべてのバージョンの SSL をデフォルトで無効にしており、TLS バージョン 1.0 についても、以下に説明するように無効にすることをお勧めします。最新の暗号化標準については、RFC 7568 を参照してください。

重要

これらの手順は Amazon Linux で使用するためのものです。他のディストリビューションのインスタンスでの LAMP ウェブサーバーのセットアップは、このチュートリアルの範囲外です。 Ubuntu の LAMP ウェブサーバーについては、Ubuntu コミュニティのドキュメントの ApacheMySQLPHP トピックを参照してください。Red Hat Enterprise Linux については、Customer Portal でウェブサーバーに関するトピックを参照してください。

前提条件

このチュートリアルを開始する前に、次のステップを完了してください。

  • EBS-backed Amazon Linux インスタンスを起動します。詳細については、「ステップ 1: インスタンスを起動する」を参照してください。

  • インスタンスが以下の TCP ポートで接続を受け付けるようにセキュリティグループを設定します。

    • SSH (ポート 22)

    • HTTP (ポート 80)

    • HTTPS (ポート 443)

    詳細については、「Amazon EC2 でのセットアップ」を参照してください。

  • Apache ウェブサーバーをインストールします。手順については、チュートリアル: Amazon Linux への LAMP ウェブサーバーのインストール」を参照してください。必要なのは http24 パッケージおよび対応する従属コンポーネントのみです。PHP および MySQL に関連する手順は無視してかまいません。

  • ウェブサイトの識別と認証を行うため、SSL/TLS の公開鍵基盤 (PKI) ではドメインネームシステム (DNS) を使用します。EC2 インスタンスを使用してパブリックウェブサイトをホストする計画がある場合は、ウェブサーバーのドメイン名を登録するか、既存のドメイン名を Amazon EC2 ホストに移す必要があります。これについては、ドメイン登録および DNS ホスティングに関するサードパーティのサービスが多数存在します。Amazon Route 53 を使用することもできます。

ステップ 1: サーバーでの SSL/TLS の有効化

この手順では、自己署名のデジタル認証を使用して、Amazon Linux で SSL/TLS をセットアップします。

注記

自己署名証明書はテスト用であり、本稼働環境では使用できません。インターネットに自己署名証明書を公開すると、サイトへの訪問者にセキュリティ警告が表示されます。

サーバーで SSL/TLS を有効にするには

  1. インスタンスに接続し、Apache が実行されていることを確認します。

    Copy
    [ec2-user ~]$ sudo service httpd status

    必要であれば、Apache を起動します。

    Copy
    [ec2-user ~]$ sudo service httpd start
  2. すべてのソフトウェアパッケージが最新の状態であることを確認するため、インスタンスでソフトウェアの更新を実行します。この処理には数分かかりますが、最新の更新とバグ修正を確実に適用することが重要です。

    注記

    -y オプションを指定すると、確認メッセージを表示せずに更新をインストールします。インストール前に更新を検査する場合は、このオプションを省略できます。

    Copy
    [ec2-user ~]$ sudo yum update -y
  3. これでインスタンスが最新状態になったため、Apache モジュール mod_ssl をインストールして SSL/TLS サポートを追加します。

    Copy
    [ec2-user ~]$ sudo yum install -y mod24_ssl

    このチュートリアルでは、次に示す 3 つのインストール済みファイルを使用します。

    • /etc/httpd/conf.d/ssl.conf

      mod_ssl の設定ファイル。このファイルには、暗号化キーと証明書の場所、許可する SSL/TLS プロトコル、受け入れる暗号化アルゴリズムを Apache に指示する "ディレクティブ" が含まれています。

    • /etc/pki/tls/private/localhost.key

      Amazon EC2 ホスト用に自動生成された 2048 ビットの RSA プライベートキー。インストール時には、自己署名ホスト証明書を生成するために OpenSSL によってこのキーが使用されます。また、このキーを使用して、認証局 (CA) に送信する証明書署名リクエスト (CSR) を生成することもできます。

    • /etc/pki/tls/certs/localhost.crt

      サーバーホスト用に自動生成された、自己署名の X.509 証明書。この証明書は、SSL/TLS を使用するように Apache が正しくセットアップされているかどうかをテストする場合に役立ちます。

    .key ファイルと .crt はどちらも PEM 形式であり、この短縮化された証明書の例のように、「BEGIN」行と「END」行で囲まれ Base64 でエンコードされた ASCII 文字で構成されます。

                            -----BEGIN CERTIFICATE-----
                            MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t
                            MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK
                            DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV
                            bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy
                            ...
                            z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0
                            WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak
                            3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg==
                            -----END CERTIFICATE-----                    

    ファイル名および拡張子は利便性のためであり、関数には影響しません。証明書は、ssl.conf ファイルの関連ディレクティブが同じ名前を使用している限り、cert.crtcert.pem、またはその他のファイル名で呼び出すことができます。

    注記

    デフォルトの SSL/TLS ファイルを独自にカスタマイズしたファイルに置き換える場合は、PEM 形式であることを確認してください。

  4. Apache を再起動します。

    Copy
    [ec2-user ~]$ sudo service httpd restart

    注記

    前述のとおり、TCP 443 番ポートが EC2 インスタンスでアクセス可能であることを確認してください。

  5. Apache ウェブサーバーではポート 443 経由で HTTPS (セキュア HTTP) がサポートされるようになっています。これをテストするには、ブラウザの URL バーに、https:// というプレフィックスを指定して、EC2 インスタンスの IP アドレスまたは完全修飾ドメイン名を入力します。信頼されていない自己署名ホスト証明書を使用してサイトに接続しようとしているため、ブラウザには一連のセキュリティ警告が表示されることがあります。

    これの警告を無視し、サイトに進みます。サーバーで SSL/TLS を正しく設定できていれば、Apache のデフォルトのテストページが開きます。これで、ブラウザとサーバーの間でやり取りされるすべてのデータが安全に暗号化されるようになります。

    サイト訪問者に対して警告画面が表示されないようにするには、暗号化だけではなく、サイト所有者のパブリック認証を行うための証明書を取得する必要があります。

ステップ 2: CA 署名証明書の取得

このセクションでは、プライベートキーから証明書署名リクエスト (CSR) を生成して認証機関 (CA) に送信し、署名付きホスト証明書を取得して、これを使用できるように Apache を設定するプロセスについて説明します。

自己署名 SSL/TLS X.509 ホスト証明書は、暗号化技術上は CA 署名証明書と同じです。これらの相違は数学的なものではなく、社会的なものです。CA では、最低でもドメイン所有権を検証してから申請者に証明書を発行することを保証しています。そのため、各ウェブブラウザには、ブラウザベンダーが信頼する CA のリストが含まれています。X.509 証明書は主に、プライベートサーバーキーに対応するパブリックキーと、このパブリックキーに暗号で関連付けられている CA による署名で構成されています。HTTPS 経由でブラウザがウェブサーバーに接続すると、サーバーは、信頼された CA のリストをブラウザが確認できるように、証明書を提示します。署名者がリストに含まれている場合や、他の信頼された署名者の信頼チェーンを通じてアクセス可能である場合、ブラウザはサーバーと、高速暗号化データチャネルのネゴシエーションを行い、ページをロードします。

証明書には、リクエストの確認作業が必要であり、一般的に費用がかかるため、各社を比較することをお勧めします。よく知られている CA のリストについては、dmoztools.net のサイトを参照してください。いくつかの CA では、基本レベル証明書が無料で提供されます。なかでも最も注目すべきは Let's Encrypt プロジェクトです。このプロジェクトでは、証明書の作成および更新プロセスの自動化もサポートしています。Let's Encrypt を CA として使用する方法の詳細については、「付録: Amazon Linux での Let's Encrypt と Certbot の使用」を参照してください。

ホスト証明書の基盤にはキーがあります。2017 年時点で、政府および業界グループは、2030 年まで、ドキュメントを保護するための RSA キーに 2048 ビットの最小キー (モジュロ) サイズを使用することを推奨しています。Amazon Linux で OpenSSL によって生成されるデフォルトのモジュラスサイズは 2048 ビットです。つまり、自動生成された既存のキーは、CA 署名証明書に適しています。モジュラスサイズを大きくする、別の暗号化アルゴリズムを使用するなど、キーのカスタマイズが必要な場合は、次に示す代替手順に従ってください。

CA 署名証明書を取得するには

  1. インスタンスに接続して、/etc/pki/tls/private/ に移動します。これは、サーバーの SSL/TLS 用プライベートキーが格納されているディレクトリです。既存のホストキーを使用して CSR を生成する場合は、ステップ 3 に進んでください。

  2. (オプション) 新しいプライベートキーを生成します。いくつかのサンプル設定を次に示します。生成されたキーのどれもウェブサーバーで機能しますが、セキュリティの実装方法 (および強度) はそれぞれ異なります。

    1. 開始点として、インスタンスでデフォルトのホストキーに似た RSA キーを作成するコマンドは次のとおりです。

      Copy
      [ec2-user ~]$ sudo openssl genrsa -out custom.key 2048

      結果として生成されるファイル custom.key が、2048 ビットの RSA プライベートキーです。

    2. これより大きなモジュラスサイズを使用して、より強力な RSA キーを作成するには、次のコマンドを使用します。

      Copy
      [ec2-user ~]$ sudo openssl genrsa -out custom.key 4096

      結果として生成されるファイル custom.key が、4096 ビットの RSA プライベートキーです。

    3. パスワードで保護された 4096 ビット暗号化 RSA キーを作成するには、次のコマンドを使用します。

      Copy
      [ec2-user ~]$ sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096

      結果として、AES 128 ビット暗号化方式で暗号化された 4096 ビットの RSA プライベートキーが生成されます。

      重要

      暗号化を使用するとセキュリティを強化できますが、暗号化キーにはパスワードが必要であるため、暗号化に依存するサービスを自動的に開始することはできません。このキーを使用するたびに、SSH 接続で "abcde12345" というパスワードを指定する必要があります。

    4. RSA 暗号化は、桁数が大きい 2 つの素数の積を因数分解する困難さを安全性の根拠としているため、比較的低速になる場合があります。ただし、非 RSA 暗号化方式を使用する SSL/TLS 用のキーを作成することも可能です。同等レベルのセキュリティを提供する場合は、楕円曲線の計算に基づいたキーのほうが小さく計算処理も高速です。例を示します。

      Copy
      [ec2-user ~]$ sudo openssl ecparam -name prime256v1 -out custom.key -genkey

      この場合の出力は、prime256v1 (OpenSSL でサポートされる "名前付き曲線") を使用した 256 ビットの楕円曲線プライベートキーです。暗号化強度は (NIST によると) 2048 ビットの RSA キーよりやや優れています。

      注記

      すべての CA で、楕円曲線ベースのキーに対して RSA キーと同じレベルのサポートが提供されているわけではありません。

    新しいプライベートキーには、制限の厳しい所有権とアクセス権を設定します (所有者 = root、グループ = root、所有者のみの読み取り/書き込み)。コマンドは次のようになります。

    Copy
    [ec2-user ~]$ sudo chown root.root custom.key [ec2-user ~]$ sudo chmod 600 custom.key [ec2-user ~]$ ls -al custom.key

    上のコマンドを実行すると、次のような結果になります。

    -rw------- root root custom.key

    適切なキーを作成し、設定できたら、CSR を作成できます。

  3. 好みのキーを使用して CSR を作成します。次の例では、custom.key を使用しています。

    Copy
    [ec2-user ~]$ sudo openssl req -new -key custom.key -out csr.pem

    OpenSSL によりダイアログが開かれ、次の表に示されている情報の入力が求められます。基本的なドメイン検証済みホスト証明書については、[Common Name] 以外のフィールドはすべてオプションです。

    名前 説明
    国名 2 文字の ISO 略称 (国名コード)。 US (= 米国)
    州名 あなたが所属する組織の所在地の州または県。省略不可です。 ワシントン
    市区町村 市など、組織の場所。 シアトル
    組織名 組織の正式名称。組織名は、省略不可です。 Example Corp
    部門名 組織に関する追加情報 (存在する場合)。 Example Dept
    共通名

    この値は、ユーザーがブラウザに入力する必要のあるウェブアドレスと正確に一致します。通常、これはプレフィックス付きのホスト名またはエイリアスによるドメイン名 (www.example.com の形式) を意味します。自己署名証明書を使用し、DNS 解決なしでテストを行う場合、共通名の構成要素はホスト名のみになる場合があります。CA では、*.example.com などのワイルドカード名を許容する、よりコストの高い証明書も用意されています。

    www.example.com
    E メールアドレス サーバー管理者の E メールアドレス. someone@example.com

    最後に、OpenSSL により、オプションのチャレンジパスワードが求められます。このパスワードは CSR と、ユーザーと CA の間のトランザクションのみに適用されるため、このフィールドと、もう 1 つのオプションフィールドである、オプションの会社名については、CA の推奨事項に従ってください。CSR のチャレンジパスワードは、サーバー操作には影響しません。

    結果として生成されるファイル csr.pem には、パブリックキー、パブリックキーのデジタル署名、入札したメタデータが含まれています。

  4. CA に CSR を送信します。この作業は通常、テキストエディタで CSR ファイルを開く動作と、内容をウェブフォームにコピーする動作で構成されています。このとき、証明書に適用する 1 つ以上のサブジェクト代替名 (SAN) を指定するように求められることがあります。共通名が www.example.com の場合、有効な SAN は example.com になります (逆も同様です)。サイトへの訪問者がこれら名前のいずれかを入力すると、エラーなしの接続が提示されます。CA のウェブフォームで許可される場合は、SAN のリストに共通名を含めます 一部の CA では自動的に含められます。

    リクエストが承認されると、CA によって署名された新しいホスト証明書が届きます。CA の信頼チェーンを完成するために必要な、追加の証明書が含まれている中間証明書ファイルをダウンロードするよう指示されることもあります。

    注記

    多様な用途向けに複数の形式のファイルを送信してくる CA もあります。このチュートリアルでは、PEM 形式の証明書ファイルのみ使用してください。PEM 形式のファイルには通常、.pem または .crt 拡張子が使用されます (ただし、常にこれらの拡張子が使用されるわけではありません)。どのファイルを使用すべきかわからない場合は、テキストエディタでファイルを開き、以下の行で始まる 1 つ以上のブロックを含むファイルを見つけてください。

    - - - - -BEGIN CERTIFICATE - - - - - 

    ファイルの末尾は次のようになっている必要があります。

    - - - -END CERTIFICATE - - - - -

    次のように、コマンドラインでファイルを確認することもできます。

    Copy
    [ec2-user certs]$ openssl x509 -in certificate.crt -text

    上記のコマンド行の出力を確認します。.p7b.p7c、または類似の拡張子で終了するファイルは使用しないでください。

  5. 元の自己署名ホスト証明書 localhost.crt/etc/pki/tls/certs ディレクトリから削除するか、ファイル名を変更して、新しい CA 署名証明書を (中間証明書がある場合はそれらも一緒に) そのディレクトリに置きます。

    注記

    EC2 インスタンスに新しい証明書をアップロードする方法は複数ありますが、最も簡単でわかりやすい方法は、テキストエディタ (vi、nano、メモ帳など) をローカルコンピューターとインスタンスの両方で開いて、両者の間でファイルの内容をコピーして貼り付けることです。EC2 インスタンス内でこれらの操作を実行する際には、root [sudo] 権限が必要です。こうすることで、許可やパスに問題があるかどうかをすぐに確認できます。ただし、内容をコピーする際に行を追加したり、内容を変更したりしないでください。

    /etc/pki/tls/certs ディレクトリの中から、ファイルの所有者、グループ、アクセス権の設定が制限の厳しい Amazon Linux のデフォルト (所有者 = root、グループ = root、所有者のみの読み込み/書き込み可) と一致することを確認します。コマンドは次のようになります。

    Copy
    [ec2-user certs]$ sudo chown root.root custom.crt [ec2-user certs]$ sudo chmod 600 custom.crt [ec2-user certs]$ ls -al custom.crt

    上のコマンドを実行すると、次のような結果になります。

    -rw------- root root custom.crt

    中間証明書ファイルのアクセス権は、比較的厳しくありません (所有者 = root、グループ = root、所有者による書き込み可、グループによる読み取り可、その他による読み取り可)。コマンドは次のようになります。

    Copy
    [ec2-user certs]$ sudo chown root.root intermediate.crt [ec2-user certs]$ sudo chmod 644 intermediate.crt [ec2-user certs]$ ls -al intermediate.crt

    上のコマンドを実行すると、次のような結果になります。

    -rw-r--r-- root root intermediate.crt
  6. カスタムキーを使用して CSR を作成し、ホスト証明書を取得した場合は、/etc/pki/tls/private/ ディレクトリから古いキーを削除するか、名前を変更して、同ディレクトリに新しいキーをインストールします。

    注記

    EC2 インスタンスにカスタムキーをアップロードする方法は複数ありますが、最も簡単でわかりやすい方法は、テキストエディタ (vi、nano、メモ帳など) をローカルコンピューターとインスタンスの両方で開いて、両者の間でファイルの内容をコピーして貼り付けることです。EC2 インスタンス内でこれらの操作を実行する際には、root [sudo] 権限が必要です。こうすることで、許可やパスに問題があるかどうかをすぐに確認できます。ただし、内容をコピーする際に行を追加したり、内容を変更したりしないでください。

    /etc/pki/tls/private ディレクトリの中から、ファイルの所有者、グループ、アクセス権の設定が制限の厳しい Amazon Linux のデフォルト (所有者 = root、グループ = root、所有者のみの読み込み/書き込み可) と一致することを確認します。コマンドは次のようになります。

    Copy
    [ec2-user private]$ sudo chown root.root custom.key [ec2-user private]$ sudo chmod 600 custom.key [ec2-user private]$ ls -al custom.key

    上のコマンドを実行すると、次のような結果になります。

    -rw------- root root custom.key
  7. 新しい CA 署名済みホスト証明書のファイル名 (この例では custom.crt) はおそらく古い証明書のファイル名と異なるため、/etc/httpd/conf.d/ssl.conf を編集し、Apache の SSLCertificateFile ディレクティブを使用して正しいパスとファイル名を指定します。

    Copy
    SSLCertificateFile /etc/pki/tls/certs/custom.crt

    中間証明書ファイル (この例では intermediate.crt) を受け取ったら、Apache の SSLCACertificateFile ディレクティブを使用して、次のファイルのパスとファイル名を指定します。

    Copy
    SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt

    注記

    一部の CA では、ホスト証明書と中間証明書を組み合わせて 1 つのファイルを作成するため、このディレクティブは必要ありません。CA が提供している手順を参照してください。

    カスタムのプライベートキー (この例では custom.key) をインストールした場合は、Apache の SSLCertificateKeyFile ディレクティブを使用してそのパスとファイル名を指定します。

    Copy
    SSLCertificateKeyFile /etc/pki/tls/private/custom.key
  8. /etc/httpd/conf.d/ssl.conf を保存して、Apache を再起動します。

    Copy
    [ec2-user ~]$ sudo service httpd restart

ステップ 3: セキュリティ設定のテストと強化

SSL/TLS が運用可能になりパブリックに公開されたら、実際の安全性をテストする必要があります。セキュリティセットアップの詳細な分析を無料で行うことのできる Qualys SSL Labs などのオンラインサービスを使用すると簡単です。その結果に基づき、受け入れるプロトコル、優先する暗号化方式、除外する暗号化方式を制御することによって、デフォルトのセキュリティ設定を強化するかどうかを決定できます。詳細については、Qualys のスコアの計算方法を参照してください。

重要

サーバーのセキュリティを確保するには、実際のテストが非常に重要です。小さな設定エラーによって、深刻なセキュリティ侵害やデータの損失が生じる可能性があります。調査や新たな脅威に応じて、推奨されるセキュリティ管理方法は常に変化するため、適切なサーバー管理を行うには、定期的なセキュリティ監査が不可欠です。

Qualys SSL Labs のサイトで、サーバーの完全修飾ドメイン名を www.example.com という形式で入力します。約 2 分後に、サイトに関するグレード (A から F) と、結果の詳細な内訳が届きます。以下の表は、Amazon Linux でのデフォルトの Apache 設定およびデフォルトの Certbot 証明書と同じ設定を使用しているドメインのレポートをまとめたものです。

総合評価 B
証明書 100%
プロトコルサポート 95%
キー交換 90%
暗号強度 90%

このレポートは、設定がほとんど正常であり、証明書、プロトコルサポート、キー交換、暗号強度に関して許容範囲の評価であることを示しています。設定では、前方秘匿性もサポートしています。前方秘匿性とは、プライベートキーから派生した一時 (エフェメラル) セッションキーを使用して暗号化を行う、プロトコルの機能です。これは、攻撃者がウェブサーバーの長期的なプライベートキーを所有していても、HTTPS データを復号できないことを意味します。ただし、このレポートは、全体のグレードを低下させる原因となる重大な脆弱性についても警告しており、追加の潜在的な問題を指摘しています。

  1. RC4 暗号化方式のサポート: 暗号化方式は、暗号化アルゴリズムの計算の中核です。SSL/TLS データストリームの暗号化に使用される高速の暗号化方式である RC4 は、いくつかの重大な脆弱性を持つことで知られています。修正方法は、RC4 サポートを完全に無効にすることです。また、明示的暗号順序と禁止された暗号の明示的リストも指定します。

    設定ファイル /etc/httpd/conf.d/ssl.conf で、SSLCipherSuiteSSLProxyCipherSuite のコメントアウトされた設定例を含むセクションを探します。

    Copy
    #SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 #SSLProxyCipherSuite HIGH:MEDIUM:!aNULL:!MD5

    これらの設定はそのままにして、その下に以下のディレクティブを追加します。

    注記

    ここでは読みやすくするために数行に分けて示していますが、これらの 2 つのディレクティブは 1 行に指定する必要があります。暗号化方式名はスペースで区切りません。

    Copy
    SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES:!aNULL:!eNULL:!EXPORT:!DES: !RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA SSLProxyCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384: ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES:!aNULL:!eNULL:!EXPORT:!DES: !RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

    これらの暗号化方式は、OpenSSL でサポートされている暗号化方式の長いリストのうち、一部です。これらは、以下の条件に応じて選択され、順序付けられています。

    1. 前方秘匿性のサポート

    2. Strength

    3. スピード

    4. 特定の暗号化方式、その後に暗号化方式のファミリー

    5. 許可されている暗号化方式、その後に拒否されている暗号化方式

    ランクの高い暗号化方式の名前には、ECDHE が含まれています (Elliptic Curve Diffie-Hellman Ephemeral など)。ephemeral は前方秘匿性を示します。また、RC4 は現在、リストの最後に近い位置にあり、禁止された暗号化方式に含まれています。

    デフォルトや、内容が見えない簡単なディレクティブに依存するのではなく、暗号化方式の明示的なリストを使用することをお勧めします。

    重要

    ここに示されている暗号化方式リストは、多数考えられるリストの 1 つに過ぎません。たとえば、前方秘匿性よりスピードを重視したリストが必要になることもあります。

    古いクライアントをサポートする必要性が予測される場合は、DES-CBC3-SHA 暗号化スイートを許可することができます。

    最後に、OpenSSL の更新ごとに、新しい暗号化方式が導入され古い暗号化方式が廃止されます。EC2 の Amazon Linux インスタンスを最新の状態に維持し、セキュリティに関する OpenSSL からの告知に注意して、技術分野の報道でセキュリティ面の新しい脆弱性に関するレポートを警戒してください。詳細については、Elastic Load Balancing ユーザーガイド の「Elastic Load Balancing での事前定義された SSL のセキュリティポリシー」を参照してください。

    最後に、次の行について、"#" を削除してコメント解除します。

    #SSLHonorCipherOrder on

    このコマンドは、(この場合) 前方秘匿性をサポートするものも含めて、ランクの高い暗号化方式を優先するようサーバーに強制します。このディレクティブが有効になると、サーバーは、セキュリティの弱い暗号化方式に戻る前に、セキュリティが強力な接続を確立しようとします。

  2. 廃止されるプロトコルサポート: 設定では、TLS 1.0 および 1.1 をサポートしていますが、これらのバージョンは廃止が予定されています。2018 年 6 月以降は TLS 1.2 が推奨されます。今後のプロトコルサポートに対応できるように、設定ファイル /etc/httpd/conf.d/ssl.conf を開き、行頭に # を付けて以下の行をコメントアウトしてください。

    #SSLProtocol all -SSLv3
    #SSLProxyProtocol all -SSLv3

    次に、次のディレクティブを追加します。

    Copy
    SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 SSLProxyProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2

    これらのディレクティブにより、SSL バージョン 2、3、および TLS バージョン 1.0、1.1 が明示的に無効化されます。サーバーは、クライアントが TLS の廃止されていないバージョンを使用している場合を除き、クライアントと暗号化接続を確立することを拒否するようになります。ディレクティブに含める指定が多くなるほど、サーバーの動作に対する設定内容が明確にわかりやすくなります。

    注記

    このようにして、TLS バージョン 1.0 および 1.1 を無効にすると、ごく一部の古くなったウェブブラウザによるサイトへのアクセスがブロックされるようになります。

編集した設定ファイルにこれらの変更を保存した後、Apache を再起動します。

Qualys SSL Labs でドメインをもう一度テストすると、RC4 脆弱性が解決し、次のようなサマリレポートが出力されます。

総合評価 A
証明書 100%
プロトコルサポート 100%
キー交換 90%
暗号強度 90%

トラブルシューティング

  • パスワードを指定しないと Apache ウェブサーバーが起動しません。

    これは、パスワードで保護された暗号化プライベート サーバー キーをインストールした場合は正常な動作です。

    その暗号化のキーとパスワードを削除できます。デフォルトディレクトリに custom.key という暗号化プライベート RSA キーがあり、そのパスフレーズが abcde12345 であるとすると、EC2 インスタンスで次のコマンドを実行し、このキーの非暗号化バージョンを生成してください。

    Copy
    [ec2-user ~]$ cd /etc/pki/tls/private/ [ec2-user private]$ sudo cp custom.key custom.key.bak [ec2-user private]$ sudo openssl rsa -in custom.key -passin pass:abcde12345 -out custom.key.nocrypt [ec2-user private]$ sudo mv custom.key.nocrypt custom.key [ec2-user private]$ sudo chown root.root custom.key [ec2-user private]$ sudo chmod 600 custom.key [ec2-user private]$ sudo service httpd restart

    パスワードが求められずに Apache が起動するようになります。

付録: Amazon Linux での Let's Encrypt と Certbot の使用

Let's Encrypt 認証局は、インターネット全体を暗号化するための Electronic Frontier Foundation (EFF) の取り組みの中核部分です。この目標を踏まえ、Let's Encrypt ホスト証明書は、手動による介入を最小限に抑えながら、作成、評価、インストール、保守されるように設計されています。証明書管理の自動化側面はウェブサーバー上で動作しているエージェントによって実行されます。インストールおよび設定されたエージェントは、Let's Encrypt と安全に通信して、Apache およびキー管理システム上で管理タスクを実行します。このチュートリアルでは、Certbot エージェントを使用します。このエージェントを使用することで、カスタマイズされた暗号化キーを証明書の基盤として提供するか、エージェント自身がそのデフォルト値を使用してキーを作成できます。また、「証明書の更新の自動化設定」で説明するように、手動による介入なしで定期的に証明書を更新するよう Certbot を設定することもできます。詳細については、Certbot のユーザーガイドまたはマニュアルページを参照してください。

重要

Certbot の開発者は、Amazon Linux での Certbot のサポートは実験的なものであると警告しています。何かうまくいかなければ簡単に回復できるように、Certbot をインストールする前に EBS ルートボリュームのスナップショットを作成しておくことをお勧めします。EBS スナップショットの作成方法の詳細については、「Amazon EBS スナップショットの作成」を参照してください。

Certbot のインストールと実行

Certbot は、Amazon Linux では公式にはサポートされておらず、Amazon Linux のパッケージリポジトリからも入手できませんが、インストール後は正常に機能します。以下の手順は、RHEL 6 で Certbot をインストールするための EFF のドキュメントを元にしています。

この手順では、Certbot のデフォルトの使用方法について説明します。これにより、2048 ビットの RSA キーに基づく証明書が作成されます。カスタマイズされたキーを試してみたい場合は、まず、「Let's Encrypt での ECDSA 証明書の使用」を参照してください。

  1. インスタンスで Fedora プロジェクトの Extra Packages for Enterprise Linux (EPEL) リポジトリを有効にします。Certbot のインストールスクリプトを実行するには、依存ファイルとして EPEL のパッケージが必要です。

    Copy
    [ec2-user ~]$ sudo yum-config-manager --enable epel
  2. 次のコマンドを使用して、EFF から Certbot の最新リリースを EC2 インスタンスにダウンロードします。

    Copy
    [ec2-user ~]$ wget https://dl.eff.org/certbot-auto
  3. ダウンロードしたファイルを実行可能にします。

    Copy
    [ec2-user ~]$ chmod a+x certbot-auto
  4. ルート権限で、--debug フラグを使用してファイルを実行します。

    Copy
    [ec2-user ~]$ sudo ./certbot-auto --debug
  5. "Is this ok [y/d/N]" というプロンプトが表示されたら「y」と入力し、Enter キーを押します。

  6. "Enter email address (used for urgent renewal and security notices)" というプロンプトが表示されたら、連絡先住所を入力し、Enter キーを押します。

  7. プロンプトが表示されたら Let's Encrypt のサービス利用規約に同意します。「A」と入力し、Enter キーを押します。

    -------------------------------------------------------------------------------
    Please read the Terms of Service at
    https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf. You must agree
    in order to register with the ACME server at
    https://acme-v01.api.letsencrypt.org/directory
    -------------------------------------------------------------------------------
    (A)gree/(C)ancel: A
  8. 「Y」または「N」と入力し、Enter キーを押してすべての承認を完了すると、EFF のメーリングリストに登録されます。

  9. 以下のプロンプトで、共通名 (上記のドメイン名) とサブジェクトの別名 (SAN) をカンマで区切って入力します。Enter キーを押します。この例では、入力した名前が提供されています。

    No names were found in your configuration files. Please enter in your domain
    name(s) (comma and/or space separated)  (Enter 'c' to cancel):example.com www.example.com
  10. Apache のデフォルト設定を使用した Amazon Linux システムでは、次の例のような出力が表示され、入力した最初の名前について尋ねられます。「1」 と入力して、Enter キーを押します。

    Obtaining a new certificate
    Performing the following challenges:
    tls-sni-01 challenge for example.com
    tls-sni-01 challenge for www.example.com
    
    We were unable to find a vhost with a ServerName or Address of example.com.
    Which virtual host would you like to choose?
    (note: conf files with multiple vhosts are not yet supported)
    -------------------------------------------------------------------------------
    1: ssl.conf                       |                       | HTTPS | Enabled
    -------------------------------------------------------------------------------
    Press 1 [enter] to confirm the selection (press 'c' to cancel): 1
  11. 次に、2 番目の名前について尋ねられます。「1」 と入力して、Enter キーを押します。

    We were unable to find a vhost with a ServerName or Address of www.example.com.
    Which virtual host would you like to choose?
    (note: conf files with multiple vhosts are not yet supported)
    -------------------------------------------------------------------------------
    1: ssl.conf                       |                       | HTTPS | Enabled
    -------------------------------------------------------------------------------
    Press 1 [enter] to confirm the selection (press 'c' to cancel): 1

    この時点で、キーと CSR が作成されます。

    Waiting for verification...
    Cleaning up challenges
    Generating key (2048 bits): /etc/letsencrypt/keys/0000_key-certbot.pem
    Creating CSR: /etc/letsencrypt/csr/0000_csr-certbot.pem
  12. Certbot にすべての必要なホスト証明書の作成を許可します。各名前の入力を求められたら、例のように、「1」と入力して、Enter キーを押します。

    We were unable to find a vhost with a ServerName or Address of example.com.
    Which virtual host would you like to choose?
    (note: conf files with multiple vhosts are not yet supported)
    -------------------------------------------------------------------------------
    1: ssl.conf                       |                       | HTTPS | Enabled
    -------------------------------------------------------------------------------
    Press 1 [enter] to confirm the selection (press 'c' to cancel): 1
    Deploying Certificate for example.com to VirtualHost /etc/httpd/conf.d/ssl.conf
    
    We were unable to find a vhost with a ServerName or Address of www.example.com.
    Which virtual host would you like to choose?
    (note: conf files with multiple vhosts are not yet supported)
    -------------------------------------------------------------------------------
    1: ssl.conf                       | example.com        | HTTPS | Enabled
    -------------------------------------------------------------------------------
    Press 1 [enter] to confirm the selection (press 'c' to cancel): 1
    Deploying Certificate for www.example.com to VirtualHost /etc/httpd/conf.d/ssl.conf
  13. ウェブサーバーへの安全でない接続を許可するかどうかを選択します。例のようにオプション 2 を選択すると、サーバーへのすべての接続が暗号化されるか、拒否されます。

    Please choose whether HTTPS access is required or optional. 
    -------------------------------------------------------------------------------
    1: Easy - Allow both HTTP and HTTPS access to these sites
    2: Secure - Make all requests redirect to secure HTTPS access
    -------------------------------------------------------------------------------
    Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2

    Apache の設定が完了し、成功した旨とその他の情報が報告されます。

    Congratulations! You have successfully enabled https://example.com and
    https://www.example.com
    
    You should test your configuration at:
    https://www.ssllabs.com/ssltest/analyze.html?d=example.com
    https://www.ssllabs.com/ssltest/analyze.html?d=www.example.com
    -------------------------------------------------------------------------------
    
    IMPORTANT NOTES:
     - Congratulations! Your certificate and chain have been saved at
       /etc/letsencrypt/live/example.com/fullchain.pem. Your cert will
       expire on 2017-07-19. To obtain a new or tweaked version of this
       certificate in the future, simply run certbot-auto again with the
       "certonly" option. To non-interactively renew *all* of your
       certificates, run "certbot-auto renew"
    ....
  14. インストールが完了したら、「ステップ 3: セキュリティ設定のテストと強化」に記載されている手順に従って、サーバーのセキュリティのテストと最適化を行います。

証明書の更新の自動化設定

Certbot は、サーバーシステムを構成する不可視のエラー回復性のあるパーツとなるように設計されています。デフォルトでは、90 日間の短い有効期限を持つホスト証明書を生成します。システムが certbot コマンドを自動的に呼び出すことを事前に許可していない場合は、同コマンドを有効期限前に手動で再実行します。以下の手順は、cron ジョブを設定して Certbot を自動化する方法を示しています。

  1. Certbot が最初に正常に実行されたら、テキストエディタで /etc/crontab ファイルを開き、次のような行を追加します。

    39      1,13    *       *       *       root    /home/ec2-user/certbot-auto renew --no-self-upgrade

    以下に、各構成要素について説明します。

    39 2,14 * * *

    毎日、02:39 と 14:39 にコマンドが実行されるようにスケジュールします。ここで選択した値は任意ですが、Certbot 開発者は、コマンドを毎日 2 回実行することを推奨しています。

    root

    コマンドは、root 権限で実行されます。

    /home/ec2-user/certbot-auto renew --no-self-upgrade

    実行されるコマンド。パス (/home/ec2-user/) は、Certbot がデフォルトのユーザーホームディレクトリにインストールされたと仮定したものです。必要に応じて修正してください。renew サブコマンドを実行すると、Certbot は、以前に取得した証明書があれば確認し、有効期限が近づいているものを更新します。--no-self-upgrade フラグにより、Certbot が手動による介入なしで自動的にアップグレードされることを禁止しています。

    完了したらファイルを保存します。

  2. cron デーモンを再起動します。

    Copy
    [ec2-user ~]$ sudo service crond restart