翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# チュートリアル: AL2 で SSL/TLS を設定する
Secure Sockets Layer/Transport Layer Security (SSL/TLS) は、ウェブサーバーとウェブクライアントの間に、転送中のデータが傍受されないように保護する、暗号化されたチャネルを確立します。このチュートリアルでは、AL2 および Apache ウェブサーバーを使用する EC2 インスタンスで SSL/TLS のサポートを手動で追加する方法について説明します。このチュートリアルでは、ロードバランサーを使用していないことを前提としています。Elastic Load Balancing を使用している場合は、代わりに [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) の証明書を使用して、ロードバランサーで SSL オフロードを設定できます。
歴史的経緯から、ウェブの暗号化は、単純に SSL と呼ばれることが少なくありません。ウェブブラウザでは今でも SSL がサポートされていますが、後継プロトコルである TLS プロトコルの方が攻撃を受けにくくなります。AL2 は、デフォルトですべてのバージョンの SSL のサーバー側のサポートを無効にします。[セキュリティ標準化団体](https://www.ssl.com/article/deprecating-early-tls/)は、TLS 1.0 は安全でないとみなしています。TLS 1.0 および TLS 1.1 は、2021 年 3 月に正式に[非推奨になりました](https://datatracker.ietf.org/doc/rfc8996/)。このチュートリアルは、TLS 1.2 を有効にすることを前提としたガイダンスです。TLS 1.3 は 2018 年に最終化され、基盤となる TLS ライブラリ (このチュートリアルでは OpenSSL) がサポートされているため、有効に設定されている限り、AL2 で利用できます。[クライアントは 2023 年 6 月 28 日までに TLS 1.2 以降をサポートしている必要があります](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/)。最新の暗号化基準の詳細については、「[RFC 7568](https://tools.ietf.org/html/rfc7568)」および「[RFC 8446](https://tools.ietf.org/html/rfc8446)」を参照してください。
このチュートリアルでは、現代のウェブ暗号化を単に TLS と呼びます。
**重要**
これらの手順は、AL2 での使用を目的としています。また、新しい Amazon EC2 インスタンスを使用して開始するものと仮定します。別のディストリビューションを実行している EC2 インスタンス、または古いバージョンの AL2 を実行しているインスタンスを設定しようとすると、このチュートリアルの一部の手順が機能しない場合があります。Ubuntu については、[Ubuntu 上の OpenSSL](https://help.ubuntu.com/community/OpenSSL) に関するコミュニティドキュメントを参照してください。Red Hat Enterprise Linux については、以下を参照してください。[Apache HTTP Web サーバーの設定](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/setting-apache-http-server_deploying-different-types-of-servers)。その他のディストリビューションについては、それぞれのドキュメントを参照してください。
**注記**
または、 AWS Nitro Enclaves に AWS Certificate Manager (ACM) を使用することもできます。これは、 AWS Nitro Enclaves で Amazon EC2 インスタンスで実行されているウェブアプリケーションとサーバーでパブリックおよびプライベートの SSL/TLS 証明書を使用できるようにするエンクレーブアプリケーションです。Nitro Enclavesは、SSL/TLS 証明書やプライベートキーなどの機密性の高いデータを保護し、安全に処理するために、分離されたコンピューティング環境を作成できる Amazon EC2 の機能です。
Nitro Enclaves 向け ACM では、Amazon EC2 Linux インスタンスで実行する **nginx** を使用することで、プライベートキーの作成、証明書とプライベートキーの配布、および証明書の更新を実行します。
Nitro Enclaves 向け ACM を使用するには、エンクレーブ対応の Linux インスタンスを使用する必要があります。
詳細については、[AWS 「Nitro Enclaves とは」を参照してください。](https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html) [AWS Certificate Manager Nitro Enclaves ユーザーガイド](https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave-refapp.html)*AWS の Nitro Enclaves* 用 および 。
**Topics**
+ [
## 前提条件
](#ssl_prereq)
+ [
## ステップ 1: サーバーで TLS を有効にする
](#ssl_enable)
+ [
## ステップ 2: CA 署名証明書を取得する
](#ssl_certificate)
+ [
## ステップ 3: セキュリティ設定をテストして強化する
](#ssl_test)
+ [
## トラブルシューティング
](#troubleshooting)
## 前提条件
このチュートリアルを開始する前に、次のステップを完了してください。
+ Amazon EBS ベースの AL2 インスタンスを起動します。詳細については、*Amazon EC2 ユーザーガイド* の [インスタンスの起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) を参照してください。
+ インスタンスが以下の TCP ポートで接続を受け付けるようにセキュリティグループを設定します。
+ SSH (ポート 22)
+ HTTP (ポート 80)
+ HTTPS (ポート 443)
詳細については、「*Amazon EC2 ユーザーガイド*」の「[セキュリティグループのルール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html)」を参照してください。
+ Apache ウェブサーバーをインストールします。step-by-stepの手順については、[「チュートリアル: AL2 に LAMP ウェブサーバーをインストールする](ec2-lamp-amazon-linux-2.md)」を参照してください。必要なのは httpd パッケージおよび対応する従属コンポーネントのみです。PHP および MariaDB に関連する手順は無視してかまいません。
+ ウェブサイトの識別と認証を行うため、TLS の公開鍵基盤 (PKI) ではドメインネームシステム (DNS) を使用します。EC2 インスタンスを使用してパブリックウェブサイトをホストするには、ウェブサーバーのドメイン名を登録するか、既存のドメイン名を Amazon EC2 ホストに移す必要があります。これについては、ドメイン登録および DNS ホスティングに関するサードパーティのサービスが多数存在します。[Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html) を使用することもできます。
## ステップ 1: サーバーで TLS を有効にする
**オプション: オートメーション を使用してこのチュートリアルを完了する**
以下のタスクの代わりに AWS Systems Manager 自動化を使用してこのチュートリアルを完了するには、[自動化ドキュメント](https://console.aws.amazon.com/systems-manager/documents/AWSDocs-Configure-SSL-TLS-AL2/)を実行します。
この手順では、自己署名デジタル証明書を使用して AL2 で TLS を設定するプロセスについて説明します。
**注記**
自己署名証明書はテスト用であり、本稼働環境では使用できません。インターネットに自己署名証明書を公開すると、サイトへの訪問者にセキュリティ警告が表示されます。
**サーバーで TLS を有効にするには**
1. [インスタンスに接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)し、Apache が実行されていることを確認します。
```
[ec2-user ~]$ sudo systemctl is-enabled httpd
```
返される値が「enabled」でない場合、Apache を起動し、システムブート時に毎回起動されるように設定します。
```
[ec2-user ~]$ sudo systemctl start httpd && sudo systemctl enable httpd
```
1. すべてのソフトウェアパッケージが最新の状態であることを確認するため、インスタンスでソフトウェアの更新を実行します。この処理には数分かかりますが、最新の更新とバグ修正を確実に適用することが重要です。
**注記**
`-y` オプションを指定すると、確認メッセージを表示せずに更新をインストールします。インストール前に更新を検査する場合は、このオプションを省略できます。
```
[ec2-user ~]$ sudo yum update -y
```
1. これでインスタンスが最新状態になったため、Apache モジュール `mod_ssl` をインストールして TLS サポートを追加します。
```
[ec2-user ~]$ sudo yum install -y mod_ssl
```
次のファイルがインスタンスに作成されました。このファイルは、セキュアサーバーの設定とテスト用の証明書の作成に使用します。
+ `/etc/httpd/conf.d/ssl.conf`
mod\$1ssl の設定ファイル。このファイルには、暗号化キーと証明書の場所、許可する TLS プロトコル、受け入れる暗号化アルゴリズムを Apache に指示する*ディレクティブ*が含まれています。
+ `/etc/pki/tls/certs/make-dummy-cert`
サーバーホスト用の自己署名 X.509 証明書とプライベートキーを生成するためのスクリプト。この証明書は、TLS を使用するように Apache が正しくセットアップされているかどうかをテストする場合に役立ちます。アイデンティティは証明されないため、本稼働環境では使用しないでください。本稼働環境で使用すると、ウェブブラウザで警告が表示されます。
1. テスト用に自己署名のダミー証明書とキーを生成するためのスクリプトを実行します。
```
[ec2-user ~]$ cd /etc/pki/tls/certs
sudo ./make-dummy-cert localhost.crt
```
`/etc/pki/tls/certs/` ディレクトリに新しいファイル `localhost.crt` が生成されます。指定されたファイル名は、**SSLCertificateFile** の `/etc/httpd/conf.d/ssl.conf` ディレクティブで割り当てたデフォルトの名前と一致します。
このファイルには、自己署名証明書と証明書のプライベートキーのいずれも含まれます。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 形式であることを確認してください。
1. ルートユーザーとしてお好みのテキストエディタ (**vim**、**nano**など) を使用して `/etc/httpd/conf.d/ssl.conf` ファイルを開き、次の行をコメントアウトします。ダミーの自己署名証明書にも同じキーが含まれているためです。次のステップに進む前にこの行をコメントアウトしないと、Apache サービスは起動に失敗します。
```
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
```
1. Apache を再起動します。
```
[ec2-user ~]$ sudo systemctl restart httpd
```
**注記**
前述のとおり、TCP 443 番ポートが EC2 インスタンスでアクセス可能であることを確認してください。
1. 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 のリストをブラウザが確認できるように、証明書を提示します。Signerがリストに含まれている場合や、他の信頼された署名者の*信頼チェーン*を通じてアクセス可能である場合、ブラウザはサーバーと、高速暗号化データチャネルのネゴシエーションを行い、ページをロードします。
証明書には、リクエストの確認作業が必要であり、一般的に費用がかかるため、各社を比較することをお勧めします。いくつかの CA では、基本レベル証明書が無料で提供されます。これらの CA で最も注目すべきは [Let's Encrypt](https://letsencrypt.org/) プロジェクトです。このプロジェクトでは、証明書の作成および更新プロセスの自動化もサポートしています。Let's Encrypt 証明書の使用の詳細については、「[Certbot の取得](https://eff-certbot.readthedocs.io/en/stable/install.html)」を参照してください。
商業グレードのサービスを提供する予定がある場合は、[AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) は良い選択肢です。
ホスト証明書の基盤にはキーがあります。2019 年時点で、[政府](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf)および[業界グループ](https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf)は、2030 年まで、ドキュメントを保護するための RSA キーに 2048 ビットの最小キー (モジュロ) サイズを使用することを推奨しています。AL2 で OpenSSL によって生成されるデフォルトのモジュラスサイズは 2048 ビットで、CA 署名証明書での使用に適しています。次の手順では、モジュラスサイズを大きくする、別の暗号化アルゴリズムを使用するなど、キーのカスタマイズが必要な場合のオプションのステップを提供しています。
**重要**
CA 署名ホスト証明書を取得するための手順は、登録およびホスト済みの DNS ドメインを所有している場合を除き、使用しません。
**CA 署名証明書を取得するには**
1. [インスタンスに接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)して、/etc/pki/tls/private/ に移動します。サーバーの TLS 用プライベートキーは、このディレクトリに格納されます。既存のホストキーを使用して CSR を生成する場合は、ステップ 3 に進みます。
1. (オプション) 新しいプライベートキーを生成します。キー設定のいくつかのサンプルを次に示します。生成されたキーのどれもウェブサーバーで機能しますが、実装されるセキュリティの強度とタイプはそれぞれ異なります。
+ **例 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](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf) によると) 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 を作成できます。
1. 好みのキーを使用して CSR を作成します。次の例では **custom.key** を使用しています。
```
[ec2-user ~]$ sudo openssl req -new -key custom.key -out csr.pem
```
OpenSSL によりダイアログが開かれ、次の表に示されている情報の入力が求められます。基本的なドメイン検証済みホスト証明書については、[**共通名**] 以外のフィールドはすべてオプションです。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/linux/al2/ug/SSL-on-amazon-linux-2.html)
最後に、OpenSSL により、オプションのチャレンジパスワードが求められます。このパスワードは CSR と、ユーザーと CA の間のトランザクションのみに適用されるため、このフィールドと、もう 1 つのオプションフィールドである、オプションの会社名については、CA の推奨事項に従ってください。CSR のチャレンジパスワードは、サーバー操作には影響しません。
結果として生成されるファイル **csr.pem** には、パブリックキー、パブリックキーのデジタル署名、入札したメタデータが含まれています。
1. 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`、または類似のファイル拡張子で終了するファイルは使用しないでください。
1. 新しい CA 署名証明書と任意の中間証明書を `/etc/pki/tls/certs` ディレクトリに配置します。
**注記**
EC2 インスタンスに新しい証明書をアップロードする方法は複数ありますが、最も簡単でわかりやすい方法は、テキストエディタ (vi、nano、またはメモ帳など) をローカルコンピュータとインスタンスの両方で開いて、両者の間でファイルの内容をコピーして貼り付けることです。EC2 インスタンス内でこれらの操作を実行する際には、root [sudo] アクセス許可が必要です。こうすることで、許可やパスに問題があるかどうかをすぐに確認できます。ただし、内容をコピーする際に行を追加したり、内容を変更したりしないでください。
`/etc/pki/tls/certs` ディレクトリ内から、ファイルの所有権、グループ、およびアクセス許可の設定が、制限の厳しい AL2 のデフォルト (所有者 = ルート、グループ = ルート、所有者のみの読み取り/書き込み) と一致していることを確認します。以下の例では、使用するコマンドを示しています。
```
[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
```
1. CSR の作成に使用したプライベートキーを `/etc/pki/tls/private/` ディレクトリに配置します。
**注記**
EC2 インスタンスにカスタムキーをアップロードする方法は複数ありますが、最も簡単でわかりやすい方法は、テキストエディタ (vi、nano、メモ帳など) をローカルコンピュータとインスタンスの両方で開いて、両者の間でファイルの内容をコピーして貼り付けることです。EC2 インスタンス内でこれらの操作を実行する際には、root [sudo] アクセス許可が必要です。こうすることで、許可やパスに問題があるかどうかをすぐに確認できます。ただし、内容をコピーする際に行を追加したり、内容を変更したりしないでください。
`/etc/pki/tls/private` ディレクトリ内から、次のコマンドを使用して、ファイルの所有権、グループ、およびアクセス許可の設定が、制限の厳しい AL2 のデフォルト (所有者 = ルート、グループ = ルート、所有者のみの読み取り/書き込み) と一致することを確認します。
```
[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
```
1. 新しい証明書とキーファイルに合わせるには、`/etc/httpd/conf.d/ssl.conf` を編集します。
1. CA 署名のホスト証明書のパスとファイル名を Apache の `SSLCertificateFile` ディレクティブで指定します。
```
SSLCertificateFile /etc/pki/tls/certs/custom.crt
```
1. 中間証明書ファイル (この例では `intermediate.crt`) を受け取ったら、Apache の `SSLCACertificateFile` ディレクティブを使用して、次のファイルのパスとファイル名を指定します。
```
SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt
```
**注記**
一部の CA では、ホスト証明書と中間証明書を組み合わせて 1 つのファイルを作成するため、この `SSLCACertificateFile` ディレクティブは必要ありません。CA が提供している手順を参照してください。
1. プライベートキー (この例では `custom.key`) のパスとファイル名を Apache の `SSLCertificateKeyFile` ディレクティブで指定します。
```
SSLCertificateKeyFile /etc/pki/tls/private/custom.key
```
1. `/etc/httpd/conf.d/ssl.conf` を保存して、Apache を再起動します。
```
[ec2-user ~]$ sudo systemctl restart httpd
```
1. サーバーをテストするには、ブラウザの URL バーにドメイン名を入力し、プレフィックス `https://` を指定します。ブラウザによって、エラーが生成されることなく、HTTPS 経由でテストページがロードされます。
## ステップ 3: セキュリティ設定をテストして強化する
TLS が運用可能になりパブリックに公開されたら、実際の安全性をテストする必要があります。セキュリティセットアップの詳細な分析を無料で行うことのできる [Qualys SSL Labs](https://www.ssllabs.com/ssltest/analyze.html) などのオンラインサービスを使用すると簡単です。その結果に基づき、受け入れるプロトコル、優先する暗号化方式、除外する暗号化方式を制御することによって、デフォルトのセキュリティ設定を強化するかどうかを決定できます。詳細については、「[Qualys のスコアの計算方法](https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide)」を参照してください。
**重要**
サーバーのセキュリティを確保するには、実際のテストが非常に重要です。小さな設定エラーによって、深刻なセキュリティ侵害やデータの損失が生じる可能性があります。調査や新たな脅威に応じて、推奨されるセキュリティ管理方法は常に変化するため、適切なサーバー管理を行うには、定期的なセキュリティ監査が不可欠です。
[Qualys SSL Labs](https://www.ssllabs.com/ssltest/analyze.html) のサイトで、サーバーの完全修飾ドメイン名を **www.example.com** という形式で入力します。約 2 分後に、サイトに関するグレード (A から F) と、結果の詳細な内訳が届きます。次の表は、AL2 のデフォルトの Apache 設定と同じ設定で、デフォルトの Certbot 証明書を持つドメインのレポートをまとめたものです。
| | |
| --- |--- |
| 総合評価 | B |
| 証明書 | 100% |
| プロトコルサポート | 95% |
| キー交換 | 70% |
| 暗号強度 | 90% |
概要は設定がほとんど正常であることを示していますが、詳細レポートでは、いくつかの潜在的な問題が指摘されています。重大度の高い順に以下に示します。
**RC4 暗号は、特定の古いブラウザでの使用がサポートされています。**暗号は、暗号化アルゴリズムの計算の中核です。TLS データストリームの暗号化に使用される高速の暗号化方式である RC4 は、いくつかの[重大な脆弱性](http://www.imperva.com/docs/hii_attacking_ssl_when_using_rc4.pdf)を持つことで知られています。従来のブラウザをサポートするもっともな理由がない限り、この暗号化方式を無効にする必要があります。
✗**旧バージョンの TLS がサポートされています。**設定では TLS 1.0 (すでに廃止されています) と TLS 1.1 (廃止予定) がサポートされています。2018 年以降は、TLS 1.2 のみ推奨されています。
**前方秘匿性は完全にサポートされていません。**[前方秘匿性](https://en.wikipedia.org/wiki/Forward_secrecy)は、プライベートキーから派生した一時 (エフェメラル) セッションキーを使用して暗号化を行う、アルゴリズムの機能です。これは、攻撃者がウェブサーバーの長期的なプライベートキーを所有していても、HTTPS データを復号できないことを意味します。
**TLS 設定を修正し、将来への対応性を確保するには**
1. 設定ファイル `/etc/httpd/conf.d/ssl.conf` を開き、行頭に \$1 を付けて以下の行をコメントアウトしてください。
```
#SSLProtocol all -SSLv3
```
1. 次のディレクティブを追加します。
```
#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** ディレクティブを含むセクションを探し、行頭に \$1 を付けて既存の行をコメントアウトします。
```
#SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
```
1. 明示的な暗号スイートと、前方秘匿性を優先し、安全でない暗号を禁止する暗号順序を指定します。ここで使用される `SSLCipherSuite` ディレクティブは、[Mozilla SSL Configuration Generator](https://mozilla.github.io/server-side-tls/ssl-config-generator/)の出力に基づいています。これは、お客様のサーバーで実行されている特定のソフトウェアに合わせて 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 行に指定する必要があります。
1. 最後に、次の行について、行頭の \$1 を削除してコメント解除します。
```
#SSLHonorCipherOrder on
```
このディレクティブは、(この場合) 前方秘匿性をサポートするものも含めて、ランクの高い暗号化方式を優先するようサーバーに強制します。このディレクティブが有効になると、サーバーは、セキュリティの弱い暗号化方式に戻る前に、セキュリティが強力な接続を確立しようとします。
これらの手順がいずれも完了したら、変更内容を `/etc/httpd/conf.d/ssl.conf` に保存し、Apache を再起動します。
[Qualys SSL Labs](https://www.ssllabs.com/ssltest/analyze.html) でドメインをもう一度テストすると、RC4 脆弱性やその他の警告は解決し、次のようなサマリレポートが出力されます。
| | |
| --- |--- |
| 総合評価 | A |
| 証明書 | 100% |
| プロトコルサポート | 100% |
| キー交換 | 90% |
| 暗号強度 | 90% |
OpenSSL の更新ごとに、新しい暗号化方式が導入され古い暗号化方式のサポートが削除されます。EC2 AL2 インスタンスup-to-date保ち、[OpenSSL](https://www.openssl.org/) からのセキュリティに関する発表を監視し、テクニカルメディアで新しいセキュリティエクスプロイトのレポートに注意してください。
## トラブルシューティング
+ **パスワードを指定しないと 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\$1ssl を実行するとエラーが発生します。**
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 インスタンスが AL2 を実行していないことを意味します。このチュートリアルでは、公式の AL2 AMI から新しく作成されたインスタンスのみをサポートします。