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

チュートリアル: Amazon Linux 2 に SSL/TLS を設定する

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

歴史的経緯から、ウェブの暗号化は、単純に SSL と呼ばれることが少なくありません。ウェブブラウザでは今でも SSL がサポートされていますが、後継プロトコルである TLS プロトコルの方が攻撃を受けにくくなります。Amazon Linux 2 では、すべてのバージョンの SSL でサーバー側のサポートをデフォルトで無効にしています。セキュリティ基準の本文 TLS 1.0 は安全ではないと考えてください。TLS 1.0 と TLS 1.1 はどちらも正式に IETF で非推奨になる予定です。このチュートリアルは、TLS 1.2 を有効にすることを前提としたガイダンスです。(新しい TLS 1.3 プロトコルはドラフト形式には含まれますが、現時点では Amazon Linux 2 でサポートされていません。) 最新の暗号化基準の詳細については、「RFC 7568」および「RFC 8446」を参照してください。

このチュートリアルでは、現代のウェブ暗号化を単に TLS と呼びます。

重要

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

前提条件

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

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

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

    • SSH (ポート 22)

    • HTTP (ポート 80)

    • HTTPS (ポート 443)

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

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

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

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

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

注記

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

サーバーで 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 をインストールして TLS サポートを追加します。

    [ec2-user ~]$ sudo yum install -y mod_ssl

    次のファイルがインスタンスに作成されました。このファイルは、セキュアサーバーの設定とテスト用の証明書の作成に使用します。

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

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

    • /etc/pki/tls/certs/make-dummy-cert

      サーバーホスト用の自己署名 X.509 証明書とプライベートキーを生成するためのスクリプト。この証明書は、TLS を使用するように Apache が正しくセットアップされているかどうかをテストする場合に役立ちます。アイデンティティは証明されないため、本稼働環境では使用しないでください。本稼働環境で使用すると、ウェブブラウザで警告が表示されます。

  4. テスト用に自己署名のダミー証明書とキーを生成するためのスクリプトを実行します。

    [ec2-user ~]$ cd /etc/pki/tls/certs sudo ./make-dummy-cert localhost.crt

    /etc/pki/tls/certs/ ディレクトリに新しいファイル localhost.crt が生成されます。指定されたファイル名は、/etc/httpd/conf.d/ssl.confSSLCertificateFile ディレクティブで割り当てたデフォルトの名前と一致します。

    このファイルには、自己署名証明書と証明書のプライベートキーのいずれも含まれます。Apache では、証明書とキーを PEM 形式にする必要があります。これは、次の短縮化された例のように、"BEGIN" 行と "END" 行で囲まれた Base64 エンコードの ASCII 文字で構成されます。

    -----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQD2KKx/8Zk94m1q 3gQMZF9ZN66Ls19+3tHAgQ5Fpo9KJDhzLjOOCI8u1PTcGmAah5kEitCEc0wzmNeo BCl0wYR6G0rGaKtK9Dn7CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vr GvwnKoMh3DlK44D9dX7IDua2PlYx5+eroA+1Lqf32ZSaAO0bBIMIYTHigwbHMZoT ... 56tE7THvH7vOEf4/iUOsIrEzaMaJ0mqkmY1A70qQGQKBgBF3H1qNRNHuyMcPODFs 27hDzPDinrquSEvoZIggkDMlh2irTiipJ/GhkvTpoQlv0fK/VXw8vSgeaBuhwJvS LXU9HvYq0U6O4FgD3nAyB9hI0BE13r1HjUvbjT7moH+RhnNz6eqqdscCS09VtRAo 4QQvAqOa8UheYeoXLdWcHaLP -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy ... z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0 CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vrGvwnKoMh3DlK44D9dlU3 WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak 3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg== -----END CERTIFICATE-----

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

    注記

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

  5. /etc/httpd/conf.d/ssl.conf ファイルを開き、次の行をコメントアウトします。ダミーの自己署名証明書にも同じキーが含まれているためです。次のステップに進む前にこの行をコメントアウトしないと、Apache サービスは起動に失敗します。

    SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
  6. Apache を再起動します。

    [ec2-user ~]$ sudo systemctl restart httpd

    注記

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

  7. Apache ウェブサーバーではポート 443 経由で HTTPS (セキュア HTTP) がサポートされるようになっています。これをテストするには、ブラウザの URL バーに、https:// というプレフィックスを指定して、EC2 インスタンスの IP アドレスまたは完全修飾ドメイン名を入力します。

    信頼されていない自己署名ホスト証明書を使用してサイトに接続しようとしているため、ブラウザには一連のセキュリティ警告が表示されることがあります。これの警告を無視し、サイトに進みます。

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

    注記

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

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

CA 署名証明書を取得するには、次の手順に従います。

  • プライベートキーから証明書署名リクエスト (CSR) を作成します。

  • 作成した CSR を認証機関 (CA) に送信します。

  • 署名付きホスト証明書を入手する

  • 証明書を使用するように Apache を設定します

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

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

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

CA 署名ホスト証明書を取得するための手順は、登録およびホスト済みの DNS ドメインを所有している場合を除き、使用しません。

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

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

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

    • 例 1: デフォルトの RSA ホストキーを作成します。結果として生成されるファイル custom.key が、2048 ビットの RSA プライベートキーです。

      [ec2-user ~]$ sudo openssl genrsa -out custom.key
    • 例 2: これより大きなモジュラサイズを使用して、より強力な RSA キーを作成します。結果として生成されるファイル custom.key が、4096 ビットの RSA プライベートキーです。

      [ec2-user ~]$ sudo openssl genrsa -out custom.key 4096
    • 例 3: パスワードで保護された 4096 ビット暗号化 RSA キーを作成します。結果のファイル、custom.key は、AES-128 暗号で暗号化された 4096 ビットの RSA プライベートキーです。

      重要

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

      [ec2-user ~]$ sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096
    • 例 4: 非 RSA 暗号を使用してキーを作成します。RSA 暗号化は、2 つの大きな素数の積に基づくパブリックキーのサイズのために、比較的遅くなる可能性があります。ただし、非 RSA 暗号化方式を使用する 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. 新しい CA 署名証明書と任意の中間証明書を /etc/pki/tls/certs ディレクトリに配置します。

    注記

    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. 新しい証明書とキーファイルに合わせるには、/etc/httpd/conf.d/ssl.conf を編集します。

    1. CA 署名のホスト証明書のパスとファイル名を Apache の SSLCertificateFile ディレクティブで指定します。

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

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

      注記

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

    3. プライベートキー (この例では 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
  9. サーバーをテストするには、ブラウザの URL バーにドメイン名を入力し、プレフィックス https:// を指定します。ブラウザによって、エラーが生成されることなく、HTTPS 経由でテストページがロードされます。

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

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

重要

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

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

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

概要は設定がほとんど正常であることを示していますが、詳細レポートでは、いくつかの潜在的な問題が指摘されています。重大度の高い順に以下に示します。

RC4 暗号は、特定の古いブラウザでの使用がサポートされています。 暗号は、暗号化アルゴリズムの計算の中核です。TLS データストリームの暗号化に使用される高速の暗号化方式である RC4 は、いくつかの重大な脆弱性を持つことで知られています。従来のブラウザをサポートするもっともな理由がない限り、この暗号化方式を無効にする必要があります。

旧バージョンの TLS がサポートされています。 設定では TLS 1.0 (すでに廃止されています) と TLS 1.1 (廃止予定) がサポートされています。2018 年以降は、TLS 1.2 のみ推奨されています。

前方秘匿性は完全にサポートされていません。 前方秘匿性は、プライベートキーから派生した一時 (エフェメラル) セッションキーを使用して暗号化を行う、アルゴリズムの機能です。これは、攻撃者がウェブサーバーの長期的なプライベートキーを所有していても、HTTPS データを復号できないことを意味します。

TLS 設定を修正し、将来への対応性を確保するには

  1. 設定ファイル /etc/httpd/conf.d/ssl.conf を開き、行頭に # を付けて以下の行をコメントアウトしてください。

    #SSLProtocol all -SSLv3
  2. 次のディレクティブを追加します。

    #SSLProtocol all -SSLv3 SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2

    このディレクティブにより、SSL バージョン 2、3、および TLS バージョン 1.0、1.1 が明示的に無効化されます。これで、サーバーでは、TLS 1.2 以外を使用した、クライアントとの暗号化された接続の受け入れが拒否されます。ディレクティブに含める指定が多くなるほど、サーバーの動作に対する設定内容が明確に伝わります。

    注記

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

許可された暗号のリストを変更するには

  1. 設定ファイル /etc/httpd/conf.d/ssl.conf で、SSLCipherSuite ディレクティブを含むセクションを探し、行頭に # を付けて既存の行をコメントアウトします。

    #SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
  2. 明示的な暗号スイートと、前方秘匿性を優先し、安全でない暗号を禁止する暗号順序を指定します。ここで使用される SSLCipherSuite ディレクティブは、Mozilla SSL Configuration Generatorの出力に基づいています。これは、お客様のサーバーで実行されている特定のソフトウェアに合わせて TLS 設定を調整します。(詳細については、Mozilla の有益なリソース「Security/Server Side TLS」を参照してください。) まず、以下のコマンドの出力を使用して、Apache と OpenSSL のバージョンを確認します。

    [ec2-user ~]$ yum list installed | grep httpd [ec2-user ~]$ yum list installed | grep openssl

    たとえば、返された情報が Apache 2.4.34 および OpenSSL 1.0.2 である場合、これをジェネレーターに入力します。"最新" 互換性モデルを選択すると、SSLCipherSuite ディレクティブが作成されます。このディレクティブは、積極的にセキュリティを適用しますが、ほとんどのブラウザで使用できます。ソフトウェアで最新互換性モデルがサポートされていない場合は、ソフトウェアを更新するか、"中間" の構成を選択します。

    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

    選択された暗号化方式の名前には、ECDHE が含まれています (Elliptic Curve Diffie-Hellman Ephemeral の略語です)。ephemeral は前方秘匿性を示します。また、これらの暗号化方式では、RC4 はサポートされていません。

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

    生成されたディレクティブを /etc/httpd/conf.d/ssl.conf にコピーします。

    注記

    ここでは読みやすくするために数行に分けて示していますが、このディレクティブは、/etc/httpd/conf.d/ssl.conf にコピーする際に、暗号化方式名の間をコロンのみ (スペースなし) で区切り、1 行に指定する必要があります。

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

    #SSLHonorCipherOrder on

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

これらの手順がいずれも完了したら、変更内容を /etc/httpd/conf.d/ssl.conf に保存し、Apache を再起動します。

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

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

重要

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

トラブルシューティング

  • パスワードを指定しないと 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 から新しく作成されたインスタンスのみをサポートしています。

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

  • 開始する前に、Amazon 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: 12949+175 epel-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 - Debug enabled: 2890 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: 778+12 epel-testing-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Debug enabled: 107 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 のインストールと実行

この手順は、Certbot を FedoraRHEL 7 にインストールするための 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 キーを押します。

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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-v02.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/certbot.oneeyedman.net/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/certbot.oneeyedman.net/privkey.pem Your cert will expire on 2019-08-01. 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 は、サーバーシステムを構成する不可視のエラー回復性のあるパーツとなるように設計されています。デフォルトでは、90 日間の短い有効期限を持つホスト証明書を生成します。システムがコマンドを自動的に呼び出すように設定していない場合は、certbot コマンドを有効期限前に手動で再実行する必要があります。以下の手順は、cron ジョブを設定して Certbot を自動化する方法を示しています。

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