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

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

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

注記

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

重要

これらの手順は Amazon Linux 2 で使用するためのものです。また、新しい EC2 インスタンスを使用して開始するものと仮定します。他のディストリビューションのインスタンスで LAMP ウェブサーバーをセットアップする場合や、古い既存のインスタンスを再利用する場合は、このチュートリアルの一部の手順を使用できないことがあります。Ubuntu の LAMP ウェブサーバーについては、Ubuntu コミュニティのドキュメントの ApacheMySQLPHP トピックを参照してください。Red Hat Enterprise Linux については、Customer Portal のウェブサーバーに関するトピックを参照してください。

Amazon Linux 1 をサポートするこのチュートリアルのバージョンは現在メンテナンスされていませんが、Internet Archive で探すことができます。

前提条件

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

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

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

    • SSH (ポート 22)

    • HTTP (ポート 80)

    • HTTPS (ポート 443)

    詳細については、「Linux インスタンス用の受信トラフィックの認可」を参照してください。

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

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

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

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

注記

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

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

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

    [ec2-user ~]$ sudo systemctl is-enabled httpd

    返される値が「enabled」でない場合、Apache を起動し、システムブート時に毎回起動されるように設定します。

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

    注記

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

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

    [ec2-user ~]$ sudo yum install -y mod_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) を生成することもできます。

      注記

      ディレクトリのリストにこのファイルが表示されない場合、アクセス許可の制限が原因の場合があります。ディレクトリ内で sudo ls -al を実行してみてください。

    • /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. インスタンスを再起動して再接続します。

  5. Apache を再起動します。

    [ec2-user ~]$ sudo systemctl restart httpd

    注記

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

  6. 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 2 での Let's Encrypt と Certbot の使用 2」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

      [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 用のキーを作成することも可能です。同等レベルのセキュリティを提供する場合は、楕円曲線の計算に基づいたキーのほうが小さく計算処理も高速です。例を示します。

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

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

      注記

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

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

    [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 を使用しています。

    [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 - - - - -

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

    [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 2 のデフォルト (所有者 = root、グループ = root、所有者のみの読み込み/書き込み可) と一致することを確認します。コマンドは次のようになります。

    [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、所有者による書き込み可、グループによる読み取り可、その他による読み取り可)。コマンドは次のようになります。

    [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 2 のデフォルト (所有者 = root、グループ = root、所有者のみの読み込み/書き込み可) と一致することを確認します。コマンドは次のようになります。

    [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 ディレクティブを使用して正しいパスとファイル名を指定します。

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

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

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

    注記

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

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

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

    [ec2-user ~]$ sudo systemctl restart httpd

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

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

重要

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

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

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

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

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

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

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

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

    注記

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

    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 2 インスタンスを最新の状態に維持し、セキュリティに関する OpenSSL からの告知に注意して、技術分野の報道でセキュリティ面の新しい脆弱性に関するレポートを警戒してください。詳細については、『クラシックロードバランサー 用ユーザーガイド』の「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

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

    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 インスタンスで次のコマンドを実行し、このキーの非暗号化バージョンを生成してください。

    [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 systemctl restart httpd

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

  • sudo yum install -y mod_ssl を実行するとエラーが発生します。

    SSL に必要なパッケージをインストールすると、次のようなエラーが表示されることがあります。

    Error: httpd24-tools conflicts with httpd-tools-2.2.34-1.16.amzn1.x86_64 Error: httpd24 conflicts with httpd-2.2.34-1.16.amzn1.x86_64

    これは、通常 EC2 インスタンスが Amazon Linux 2 を実行していないことを意味します。このチュートリアルでは、公式の Amazon Linux 2 AMI から新しく作成されたインスタンスのみをサポートしています。

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

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

 Certbot ロゴ

Certbot は、EFF の Let's Encrypt 証明書サービスのクライアントユーティリティです。

Certbot は Amazon Linux 2 で公式にサポートされていませんが、ダウンロードすることができ、インストールすると正常に機能します。データを保護し、問題を回避するため、次のバックアップを作成しておくことをお勧めします。

  • 開始する前に、EBS ルートボリュームのスナップショットを作成します。これにより、EC2 インスタンスの元の状態に復元することができます。EBS スナップショットの作成方法の詳細については、「Amazon EBS スナップショットの作成」を参照してください。

  • 以下の手順では、Apache の操作を制御する httpd.conf ファイルを編集する必要があります。Certbot はこのファイルと他の設定ファイルに独自の自動変更を加えます。復元する必要が生じたときのために、/etc/httpd ディレクトリ全体のバックアップコピーを作成してください。

インストールの準備

Certbot をインストールする前に、次の手順を完了します。

  1. Extra Packages for Enterprise Linux (EPEL) 7 リポジトリパッケージをダウンロードします。これは、Certbot が必要とする依存関係を提供するために必要です。

    1. ホームディレクトリ (/home/ec2-user) に移動します。次のコマンドを使って EPEL をダウンロードします。

      [ec2-user ~]$ sudo wget -r --no-parent -A 'epel-release-*.rpm' http://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/
    2. 以下のようにリポジトリパッケージをインストールします。

      [ec2-user ~]$ sudo rpm -Uvh dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-*.rpm
    3. EPEL の有効化:

      [ec2-user ~]$ sudo yum-config-manager --enable epel*

      次のコマンドを使用して EPEL が有効になっていることを確認できます。次のスニペットのような情報が返されます。

      [ec2-user ~]$ sudo yum repolist all ... !epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 enabled: 12,184+105 !epel-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 - Debug enabled: 2,717 !epel-source/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 - Source enabled: 0 !epel-testing/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 enabled: 959+10 !epel-testing-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Debug enabled: 142 !epel-testing-source/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Source enabled: 0 ...
  2. Apache のメイン設定ファイル /etc/httpd/conf/httpd.conf を編集します。「listen 80」ディレクティブを見つけてその後ろに次の行を追加します。このとき、サンプルドメイン名を、設定する実際の共通名およびサブジェクト代替名拡張子 (SAN) に置き換えます。

    <VirtualHost *:80> DocumentRoot "/var/www/html" ServerName "example.com" ServerAlias "www.example.com" </VirtualHost>

    ファイルを保存して、Apache を再起動します。

    [ec2-user ~]$ sudo systemctl restart httpd

Certbot のインストールと実行

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

  1. 次のコマンドを使用して Certbot パッケージと依存関係をインストールします。

    [ec2-user ~]$ sudo yum install -y certbot python2-certbot-apache
  2. Certbot を実行します。

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

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

    Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org ------------------------------------------------------------------------------- Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.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
  5. EFF のメーリングリストに登録するための承認で、「Y」または「N」と入力して Enter キーを押します。

  6. Certbot に、VirtualHost ブロックで入力した共通名およびサブジェクト代替名 (SAN) が表示されます。

    Which names would you like to activate HTTPS for? ------------------------------------------------------------------------------- 1: example.com 2: www.example.com ------------------------------------------------------------------------------- Select the appropriate numbers separated by commas and/or spaces, or leave input blank to select all options shown (Enter 'c' to cancel):

    入力を空白にしたまま Enter キーを押します。

  7. Certbot が証明書を作成して Apache を設定すると、次の出力が表示されます。その後、HTTP クエリを HTTPS にリダイレクトするどうかの確認が求められます。

    Obtaining a new certificate Performing the following challenges: http-01 challenge for example.com http-01 challenge for www.example.com Waiting for verification... Cleaning up challenges Created an SSL vhost at /etc/httpd/conf/httpd-le-ssl.conf Deploying Certificate for example.com to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf Enabling site /etc/httpd/conf/httpd-le-ssl.conf by adding Include to root configuration Deploying Certificate for www.example.com to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. ------------------------------------------------------------------------------- 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. ------------------------------------------------------------------------------- Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

    訪問者が暗号化されていない HTTP 経由でサーバーに接続するには、「1」と入力します。HTTPS 経由の暗号化接続のみ受け入れる場合は、「2」と入力します。Enter を押して選択内容を送信します。

  8. 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 key file has been saved at: /etc/letsencrypt/live/example.com/privkey.pem Your cert will expire on 2018-05-28. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal.
  9. インストールが完了したら、「ステップ 3: セキュリティ設定のテストと強化」に記載されている手順に従って、サーバーのセキュリティのテストと最適化を行います。

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

Certbot を自動化するには

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

  1. テキストエディタで /etc/crontab を開き、次のような行を追加します。

    39 1,13 * * * root certbot renew --no-self-upgrade

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

    39 1,13 * * *

    毎日、01:39 と 13:39 にコマンドが実行されるようにスケジュールします。ここで選択した値は任意ですが、Certbot 開発者は、コマンドを少なくとも毎日 2 回実行することを推奨しています。これにより、侵害されていることがわかった証明書は必ずすぐに取り消されて置き換えられます。

    root

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

    certbot renew --no-self-upgrade

    実行されるコマンド。renew サブコマンドを実行すると、Certbot は、以前に取得した証明書があれば確認し、有効期限が近づいているものを更新します。--no-self-upgrade フラグにより、Certbot が手動による介入なしで自動的にアップグレードされることを禁止しています。

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

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

    [ec2-user ~]$ sudo systemctl restart crond