チュートリアル: Amazon Linux 2 に SSL/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.conf の SSLCertificateFile ディレクティブで割り当てたデフォルトの名前と一致します。

   このファイルには、自己署名証明書と証明書のプライベートキーのいずれも含まれます。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 署名証明書を取得する必要があります。

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 経由でテストページがロードされます。

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

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

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' https://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 を Fedora と RHEL 7 にインストールするための EFF ドキュメントに基づいています。Certbot のデフォルトの使用方法について説明します。これにより、2048 ビットの RSA キーに基づく証明書が作成されます。

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 を自動化するには

1. sudo を使用し、テキストエディタ (vim や nano など) で /etc/crontab ファイルを開きます。または sudo crontab -e を使用します。

2. 次のような行を追加し、ファイルを保存します。

   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 が手動による介入なしで自動的にアップグレードされることを禁止しています。

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

   [ec2-user ~]$ sudo systemctl restart crond