翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Elastic Beanstalk 環境の HTTPS の設定
このセクションのこのトピックでは、Elastic Beanstalk 環境に HTTPS を設定する方法について説明します。HTTPS は、ユーザーデータやログイン情報を送信するいずれのアプリケーションにも必須です。
Elastic Beanstalk 環境用に[カスタムドメイン名](customdomains.md)を購入して設定した場合は、HTTPS を使用することで、ユーザーがウェブサイトに接続する際の安全性を確保できます。
ドメイン名を所有していない場合でも、開発およびテスト目的に自己署名証明書で、HTTPS を使用できます。詳細については、「[サーバー証明書](configuring-https.certificate.md)」を参照してください。
**ロードバランサーでの HTTPS 終端の設定**
ロードバランサーは、アプリケーションを実行する EC2 インスタンスにリクエストを分散します。ロードバランサーにより、インスタンスを直接インターネットに公開する必要もなくなります。Elastic Beanstalk マルチインスタンス環境で HTTPS を使用する最も簡単な方法は、ロードバランサーにセキュアなリスナーを設定することです。クライアントとロードバランサーとの間の接続は引き続きセキュアであるため、HTTPS を終端するようにロードバランサーを設定できます。ロードバランサーと EC2 インスタンスとの間のバックエンド接続では HTTP が使用されるため、インスタンスの追加の設定は必要ありません。セキュアなリスナーを設定する詳細な手順については、「[ロードバランサーでの HTTPS 終端の設定](configuring-https-elb.md)」を参照してください。
**EC2 インスタンスでの HTTPS 終端の設定**
単一インスタンスの環境でアプリケーションを実行したり、ロードバランサーの背後で EC2 インスタンスまで接続をセキュリティで保護する必要がある場合は、HTTPS を終了するように、インスタンス上で実行されるプロキシサーバーを設定できます。HTTPS 接続を終了するようにインスタンスを設定するには、[設定ファイル](ebextensions.md)を使用して、インスタンスで実行されるソフトウェアを変更し、セキュアな接続を許可するようにセキュリティグループを変更する必要があります。詳細については、「[インスタンスでの HTTPS 終端の設定](https-singleinstance.md)」を参照してください。
**HTTPS エンドツーエンドの設定**
負荷分散された環境でのエンドツーエンドの HTTPS の場合、インスタンスとロードバランサーの終了を組み合わせて、両方の接続を暗号化できます。デフォルトでは、HTTPS を使用するトラフィックを転送するようにロードバランサーを設定した場合、ロードバランサーはバックエンドインスタンスによって提示された証明書をすべて信頼します。セキュリティを最大限に高めるには、インスタンスによって提示された公開証明書をロードバランサーが信頼しない場合にそのインスタンスへの接続を禁止するポリシーを、ロードバランサーにアタッチできます。詳細については、「[負荷分散された Elastic Beanstalk 環境でエンドツーエンドの暗号化を設定する](configuring-https-endtoend.md)」を参照してください。
**TCP パススルーを使用した HTTPS の設定**
また、HTTPS トラフィックを復号せずに中継するように、ロードバランサーを設定することもできます。詳細については、「[環境のロードバランサーを TCP パススルー用に設定する](https-tcp-passthrough.md)」を参照してください。
**注記**
GitHub の[Does it have Snakes?](https://github.com/awslabs/eb-tomcat-snakes) サンプルアプリケーションには、Tomcat ウェブアプリケーションで HTTPS を設定する方法別に設定ファイルと手順が含まれています。詳細については、[readme ファイル](https://github.com/awslabs/eb-tomcat-snakes/blob/master/README.md)と [HTTPS に関する手順](https://github.com/awslabs/eb-tomcat-snakes/blob/master/src/.ebextensions/inactive/HTTPS.md)を参照してください。
**Topics**
+ [
# サーバー証明書
](configuring-https.certificate.md)
+ [
# ロードバランサーでの HTTPS 終端の設定
](configuring-https-elb.md)
+ [
# インスタンスでの HTTPS 終端の設定
](https-singleinstance.md)
+ [
# 負荷分散された Elastic Beanstalk 環境でエンドツーエンドの暗号化を設定する
](configuring-https-endtoend.md)
+ [
# 環境のロードバランサーを TCP パススルー用に設定する
](https-tcp-passthrough.md)
+ [
# HTTP から HTTPS へのリダイレクトの設定
](configuring-https-httpredirect.md)
# サーバー証明書
このトピックでは、HTTPS の設定に使用できるさまざまなタイプの証明書と、それぞれを適用するタイミングについて説明します。このセクションのサブトピックでは、独自の証明書を作成する手順と、それをアップロードする方法を説明します。
**AWS Certificate Manager (ACM)**
ACM は、サーバー証明書をプロビジョン、管理、デプロイするための推奨ツールです。これは、プログラムまたは を使用して行うことができます AWS CLI。ACM を使用すると、ドメイン名用の信頼された証明書を無料で作成できます。
ACM 証明書は AWS ロードバランサーと Amazon CloudFront ディストリビューションでのみ使用でき、ACM は特定の AWS リージョンでのみ使用できます。Elastic Beanstalk で ACM 証明書を使用するには、「[ロードバランサーでの HTTPS 終端の設定](configuring-https-elb.md)」を参照してください。ACM の詳細については、「[AWS Certificate Manager ユーザーガイド](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)」を参照してください。
**注記**
ACM を使用できるリージョンのリストについては、「Amazon Web Services 全般のリファレンス」の「ACM のエンドポイントとクォータ」を参照してください。
ACM が AWS リージョンで利用できない場合は、サードパーティーまたは自己署名証明書とプライベートキーを AWS Identity and Access Management (IAM) にアップロードできます。を使用して証明書 AWS CLI をアップロードできます。IAM に保存されている証明書は、ロードバランサーと CloudFront ディストリビューションで使用できます。詳細については、「[IAM に証明書をアップロードする](configuring-https-ssl-upload.md)」を参照してください。
**サードパーティー証明書**
ACM がお客様のリージョンで使用できない場合は、信頼された証明書を第三者から購入できます。第三者からの証明書はロードバランサー、バックエンドインスタンス、またはその両方で HTTPS トラフィックの復号に使用できます。
**証明書が自己署名です**
開発およびテスト目的で、オープンソースのツールを使用して自分で[証明書を作成して署名](configuring-https-ssl.md)できます。自己署名証明書は無料で簡単に作成できますが、公開サイトのフロントエンド復号化に使用することはできません。クライアントへの HTTPS 接続に自己署名証明書を使用しようとした場合、ユーザーのブラウザではウェブサイトが安全でないことを示すエラーメッセージが表示されます。ただし、バックエンド接続の保護に自己署名証明書を使用することは問題ありません。
# X509 証明書を作成し署名する
`OpenSSL` を使用してアプリケーションの X509 証明書を作成できます。OpenSSL は標準のオープンソースライブラリーで、x509 証明書の作成と署名を含む包括的な暗号関数をサポートしています。OpenSSL の詳細については、[www.openssl.org](https://www.openssl.org/) を参照してください。
**注記**
[HTTPS を単一インスタンス環境で使用する](https-singleinstance.md)か、自己署名証明書を使用して、[バックエンドで再度暗号化する](configuring-https-endtoend.md)には、証明書をローカルに作成する必要があります。ドメイン名を所有している場合は、 ( AWS Certificate Manager ACM) を使用して で証明書を作成し、ロードバランシングされた環境で無料で AWS 使用できます。手順については、*AWS Certificate Manager ユーザーガイド*の「[証明書のリクエスト](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request.html)」を参照してください。
コマンドラインで `openssl version` を実行して、OpenSSL がすでにインストールされているかどうかを確認します。OpenSSL をインストールしていない場合は、「[公開 GitHub リポジトリ](https://github.com/openssl/openssl)」の指示を使用してソースコードをインストールするか、または好みのパッケージマネージャを使用できます。OpenSSL は Elastic Beanstalk の Linux イメージにもインストールされているため、簡単な代替策として、次のように [EB CLI](eb-cli3.md) の **eb ssh** コマンドを使用して実行環境の EC2 インスタンスに接続できます。
```
~/eb$ eb ssh
[ec2-user@ip-255-55-55-255 ~]$ openssl version
OpenSSL 1.0.1k-fips 8 Jan 2015
```
証明書署名リクエスト（CSR）を作成するための RSA プライベートキーを作成する必要があります。プライベートキーを作成するには、**openssl genrsa** コマンドを使用します。
```
[ec2-user@ip-255-55-55-255 ~]$ openssl genrsa 2048 > privatekey.pem
Generating RSA private key, 2048 bit long modulus
.................................................................................................................................+++
...............+++
e is 65537 (0x10001)
```
*privatekey.pem*
プライベートキーを保存するファイルの名前です。通常、**openssl genrsa** コマンドは画面にプライベートキーの内容を表示しますが、このコマンドは出力をファイルにパイプします。任意のファイル名を選択し、ファイルを後から取得できるように安全な場所に保存します。プライベートキーをなくした場合は、証明書を使用することはできません。
CSR は、デジタルサーバー証明書を申請するために認証機関（CA）に送信するファイルです。CSR を作成するには、**openssl req** コマンドを使用します。
```
$ openssl req -new -key privatekey.pem -out csr.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
```
要求された情報を入力して、**Enter** を押します。以下の表は、各フィールドの例を表示して説明したものです。
****
| 名前 | 説明 | 例 |
| --- | --- | --- |
| 国名 | 2 文字の ISO 略称 (国名コード)。 | 例 :US = アメリカ |
| 州または県 | あなたが所属する組織の所在地の州または県。この名前を省略することはできません。 | ワシントン |
| 市区町村 | あなたが所属する組織の所在地の市区町村。 | Seattle |
| 組織名 | 組織の正式名称。組織名は、省略不可です。 | Example Corp |
| 部門名 | 追加の部門情報は、省略可能です。 | Marketing |
| 共通名 | ウェブサイトの完全修飾ドメイン名 これは、ユーザーがサイトを訪問したときに表示されるドメイン名と一致する必要があります。一致しない場合は証明書エラーが表示されます。 | www.example.com |
| E メールアドレス | サイト管理者の E メールアドレス | someone@example.com |
署名を要求する署名リクエストをサードパーティに送信するか、または開発とテスト用に自分で署名することができます。自己署名証明書は、ロードバランサーと EC2 インスタンス間のバックエンド HTTPS にも使用できます。
証明書に署名するには、**openssl x509** コマンドを使用します。以下の例では、以前のステップ (*privatekey.pem*) のプライベートキーおよび署名リクエスト (*csr.pem*) を使用して、*365* 日間有効な *public.crt* という名前の公開証明書を作成します。
```
$ openssl x509 -req -days 365 -in csr.pem -signkey privatekey.pem -out public.crt
Signature ok
subject=/C=us/ST=washington/L=seattle/O=example corporation/OU=marketing/CN=www.example.com/emailAddress=someone@example.com
Getting Private key
```
秘密キーと公開証明書は後で使用できるようにしておきます。署名リクエストは破棄できます。必ず、[プライベートキーは安全な場所に保存し](https-storingprivatekeys.md)、ソースコードには追加しないことをお勧めします。
Windows Server プラットフォームを使用して証明書を使用するには、PFX 形式に変換する必要があります。プライベートキーとパブリック証明書ファイルから PFX 証明書を作成するには、次のコマンドを使用します。
```
$ openssl pkcs12 -export -out example.com.pfx -inkey privatekey.pem -in public.crt
Enter Export Password: password
Verifying - Enter Export Password: password
```
証明書があるため、ロードバランサーで使用するために、[IAM にアップロードする](configuring-https-ssl-upload.md)か、[HTTPS を終了するように環境内のインスタンスを設定](https-singleinstance.md)します。
# IAM に証明書をアップロードする
Elastic Beanstalk 環境のロードバランサーで証明書を使用するには、証明書とプライベートキーを AWS Identity and Access Management (IAM) にアップロードします。IAM に保存されている証明書は、Elastic Load Balancing ロードバランサーおよび Amazon CloudFront ディストリビューションで使用できます。
**注記**
AWS Certificate Manager (ACM) は、サーバー証明書のプロビジョニング、管理、デプロイに推奨されるツールです。ACM 証明書のリクエストの詳細については、*AWS Certificate Manager ユーザーガイド*の「[証明書のリクエスト](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request.html)」を参照してください。ACM へのサードパーティー証明書のインポートの詳細については、*AWS Certificate Manager ユーザーガイド*の「[証明書のインポート](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html)」を参照してください。IAM を使用して証明書をアップロードするには、[AWS リージョンで ACM が使用できない場合に限ります](https://docs.aws.amazon.com/general/latest/gr/acm.html)。
AWS Command Line Interface (AWS CLI) を使用して証明書をアップロードできます。次のコマンドは、*https-cert.crt* という名前の自己署名証明書を、*private-key.pem* という名前のプライベートキーとともにアップロードします。
```
$ aws iam upload-server-certificate --server-certificate-name elastic-beanstalk-x509 --certificate-body file://https-cert.crt --private-key file://private-key.pem
{
"ServerCertificateMetadata": {
"ServerCertificateId": "AS5YBEIONO2Q7CAIHKNGC",
"ServerCertificateName": "elastic-beanstalk-x509",
"Expiration": "2017-01-31T23:06:22Z",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:server-certificate/elastic-beanstalk-x509",
"UploadDate": "2016-02-01T23:10:34.167Z"
}
}
```
`file://` プレフィックスは、現在のディレクトリにファイルの内容を読み込む AWS CLI ように に指示します。 *elastic-beanstalk-x509* は、IAM で証明書を呼び出す名前を指定します。
証明機関から証明書を購入し、証明書チェーンファイルを受け取った場合は、`--certificate-chain` オプションを含めることで、そのファイルもアップロードします。
```
$ aws iam upload-server-certificate --server-certificate-name elastic-beanstalk-x509 --certificate-chain file://certificate-chain.pem --certificate-body file://https-cert.crt --private-key file://private-key.pem
```
証明書の Amazon リソースネーム（ARN）をメモします。これは、HTTPS を使用するロードバランサー設定を更新する際に使用します。
**注記**
IAM にアップロードされた証明書は、環境のロードバランサーで使用されなくなっても保存されたままになります。これには重要なデータが含まれています。どの環境にも証明書が不要になった場合は、必ず削除してください。IAM から証明書を削除する方法の詳細については、「[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_server-certs.html#delete-server-certificate](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_server-certs.html#delete-server-certificate)」を参照してください。
IAM のサーバー証明書の詳細については、「IAM ユーザーガイド」の[サーバー証明書の使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_server-certs.html)に関するページを参照してください。
# 秘密キーを Amazon S3 に安全に保存する
パブリック証明書の署名に使用するプライベートキーはプライベートであるため、ソースコードにコミットしないでください。プライベートキーファイルを Amazon S3 にアップロードしておき、アプリケーションのデプロイ時に Amazon S3 からダウンロードされるように Elastic Beanstalk を設定することで、設定ファイルにプライベートキーを保存しなくて済みます。
以下の例で示している[設定ファイル](ebextensions.md)の[リソース](environment-resources.md)セクションと[ファイル](customize-containers-ec2.md#linux-files)セクションでは、Amazon S3 バケットからプライベートキーファイルをダウンロードしています。
**Example .ebextensions/privatekey.config**
```
Resources:
AWSEBAutoScalingGroup:
Metadata:
AWS::CloudFormation::Authentication:
S3Auth:
type: "s3"
buckets: ["elasticbeanstalk-us-west-2-123456789012"]
roleName:
"Fn::GetOptionSetting":
Namespace: "aws:autoscaling:launchconfiguration"
OptionName: "IamInstanceProfile"
DefaultValue: "aws-elasticbeanstalk-ec2-role"
files:
# Private key
"/etc/pki/tls/certs/server.key":
mode: "000400"
owner: root
group: root
authentication: "S3Auth"
source: https://elasticbeanstalk-us-west-2-123456789012.s3.us-west-2.amazonaws.com/server.key
```
例に使用しているバケット名と URL は独自のものに置き換えてください。このファイルの最初のエントリは、環境の Auto Scaling グループのメタデータに `S3Auth` という名前の認証方法を追加します。お客様の環境用にカスタム[インスタンスプロファイル](concepts-roles-instance.md)を設定している場合はそのプロファイルが使用されますが、設定していない場合は `aws-elasticbeanstalk-ec2-role` のデフォルト値が適用されます。デフォルトのインスタンスプロファイルには、Elastic Beanstalk ストレージバケットからの読み取り権限があります。別のバケットを使用する場合は、[インスタンスプロファイルに許可を追加](iam-instanceprofile.md#iam-instanceprofile-addperms)します。
2 番目のエントリは、`S3Auth` 認証方法を使用して、指定された URL からプライベートキーをダウンロードし、`/etc/pki/tls/certs/server.key` に保存します。プロキシサーバーは、この場所からプライベートキーを読み取って、[インスタンスで HTTPS 接続を終了](https-singleinstance.md)できます。
環境の EC2 インスタンスに割り当てられるインスタンスプロファイルには、指定したバケットからキーオブジェクトを読み取るための権限がなければなりません。[インスタンスプロファイルに IAM のオブジェクトを読み取るアクセス許可があること](iam-instanceprofile.md#iam-instanceprofile-verify)と、バケットおよびオブジェクトに対するアクセス許可でインスタンスプロファイルが禁止されていないことを確認します。
**バケットの権限を表示するには**
1. [Amazon S3 マネジメントコンソール](https://console.aws.amazon.com/s3/home)を開きます。
1. バケットを選択します。
1. [**プロパティ**] を選択して、[**アクセス許可**] を選択します。
1. アカウントがバケットの読み取り権限を持っていることを確認します。
1. バケットポリシーがアタッチされている場合は、[**バケットポリシー**] を選択して、バケットに割り当てられているアクセス許可を表示します。
# ロードバランサーでの HTTPS 終端の設定
HTTPS を使用するように AWS Elastic Beanstalk 環境を更新するには、環境でロードバランサーの HTTPS リスナーを設定する必要があります。HTTPS リスナーは、Classic Load Balancer とApplication Load Balancer の 2 種類のロードバランサーをサポートします。
Elastic Beanstalk コンソールまたは設定ファイルのいずれかを使用して、セキュアリスナーを設定し、証明書を割り当てることができます。
**注記**
単一インスタンス環境にはロードバランサーが存在せず、ロードバランサーでは HTTPS 接尾辞はサポートされません。
## Elastic Beanstalk コンソールを使用したセキュアリスナーの設定
**お客様の環境のロードバランサーに証明書を割り当てるには**
1. [Elastic Beanstalk コンソール](https://console.aws.amazon.com/elasticbeanstalk)を開き、**リージョン**リストで を選択します AWS リージョン。
1. ナビゲーションペインで、[**環境**] を選択し、リストから環境の名前を選択します。
1. ナビゲーションペインで、[**設定**] を選択します。
1. [**ロードバランサー**] 設定カテゴリで、[**編集**] を選択します。
**注記**
[**ロードバランサー**] 設定カテゴリに [**編集**] ボタンがない場合、お客様の環境には[ロードバランサー](using-features-managing-env-types.md#using-features.managing.changetype)がありません。
1. [**ロードバランサーの変更**] ページの手順は、環境に関連付けられるロードバランサーのタイプによって異なります。
+ **Classic Load Balancer**
1. **[リスナーの追加]** を選択します。
1. [**Classic Load Balancer リスナー**] ダイアログボックスで次の設定を構成します。
+ [**リスナーポート**] に着信トラフィックポートを入力します (通常の場合は、`443`)。
+ [**リスナープロトコル**] で [**HTTPS**] を選択します。
+ [**インスタンスポート**] に `80` と入力します。
+ [**インスタンスのプロトコル**] で [**HTTP**] を選択します。
+ [**SSL 証明書**] で、証明書を選択します。
1. **[Add]** (追加) を選択します。
+ **Application Load Balancer**
1. **[リスナーの追加]** を選択します。
1. [**Application Load Balancer リスナー**] ダイアログボックスで次の設定を構成します。
+ [**ポート**] で着信トラフィックポートを入力します (通常の場合は、`443`)。
+ [**プロトコル**] として [**HTTPS**] を選択します。
+ [**SSL 証明書**] で、証明書を選択します。
1. **[Add]** (追加) を選択します。
**注記**
Classic Load Balancer および Application Load Balancer について、ドロップダウン・メニューに証明書が表示されない場合は、[AWS Certificate Manager (ACM)](https://docs.aws.amazon.com/acm/latest/userguide/) で[カスタムドメイン名](customdomains.md)の証明書を作成またはアップロードします (推奨)。または、 AWS CLIで 証明書を IAM にアップロードします。
+ **Network Load Balancer**
1. **[リスナーの追加]** を選択します。
1. [**Network Load Balancer リスナー**] ダイアログボックスで、[**ポート**] に着信トラフィックポート (通常は `443`) を入力します。
1. **[Add]** (追加) を選択します。
1. ページの最下部で **[適用]** を選択し変更を保存します。
## 設定ファイルを使用したセキュアリスナーの設定
次のいずれかの [設定ファイル](ebextensions.md)を使用して、ロードバランサーに対してセキュアなリスナーを設定できます。
**Example .ebextensions/securelistener-clb.config**
この例は、環境に Classic Load Balancer がある場合に使用します。この例では、 指定した証明書を使用して ポート 443 の HTTPS リスナーを設定し、復号化されたトラフィックがポート 80 上でお客様の環境内のインスタンスに転送されるように、`aws:elb:listener` 名前空間のオプションを使用します。
```
option_settings:
aws:elb:listener:443:
SSLCertificateId: arn:aws:acm:us-east-2:1234567890123:certificate/####################################
ListenerProtocol: HTTPS
InstancePort: 80
```
強調表示されたテキストを証明書の ARN に置き換えます。証明書は、 AWS Certificate Manager (ACM) で作成またはアップロードした証明書 (推奨) でも、 を使用して IAM にアップロードした証明書でもかまいません AWS CLI。
Classic Load Balancer の設定オプションの詳細については、「[Classic Load Balancer 設定の名前空間](environments-cfg-clb.md#environments-cfg-clb-namespace)」を参照してください。
**Example .ebextensions/securelistener-alb.config**
この例は、環境に Application Load Balancer がある場合に使用します。この例では、`aws:elbv2:listener` 名前空間内のオプションを使用して、指定した証明書によりポート 443 上の HTTPS リスナーを設定しています。リスナーは、デフォルトのプロセスにトラフィックをルーティングします。
```
option_settings:
aws:elbv2:listener:443:
ListenerEnabled: 'true'
Protocol: HTTPS
SSLCertificateArns: arn:aws:acm:us-east-2:1234567890123:certificate/####################################
```
**Example .ebextensions/securelistener-nlb.config**
この例は、環境に Network Load Balancer がある場合に使用します。この例では、`aws:elbv2:listener` 名前空間内のオプションを使用して、ポート 443 のリスナーを設定します。リスナーは、デフォルトのプロセスにトラフィックをルーティングします。
```
option_settings:
aws:elbv2:listener:443:
ListenerEnabled: 'true'
```
## セキュリティグループを設定する
ポート 80 以外のインスタンスポートにトラフィックを転送するようにロードバランサーを設定する場合は、ロードバランサーからのインスタンスポート上のインバウンドトラフィックを許可するルールをセキュリティグループに追加する必要があります。カスタム VPC で環境を作成すると、Elastic Beanstalk によってこのルールが自動的に追加されます。
このルールは、`Resources` キーを、アプリケーションの `.ebextensions` ディレクトリにある[設定ファイル](ebextensions.md)に追加することで追加できます。
次の設定ファイルの例では、`AWSEBSecurityGroup` セキュリティグループに進入ルールを追加します。これにより、ロードバランサーのセキュリティグループからポート 1000 へのトラフィックが許可されます。
**Example .ebextensions/sg-ingressfromlb.config**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 1000
FromPort: 1000
SourceSecurityGroupId: {"Fn::GetAtt" : ["AWSEBLoadBalancerSecurityGroup", "GroupId"]}
```
# インスタンスでの HTTPS 終端の設定
[設定ファイル](ebextensions.md)を使用して、アプリケーションにトラフィックを渡すプロキシサーバーを設定し、HTTPS 接続を終了できます。これは、単一インスタンス環境で HTTPS を使用している場合、またはトラフィックを復号化しないで渡すようにロードバランサーを設定している場合に便利です。
HTTPS を有効にするには、Elastic Beanstalk アプリケーションが実行されている EC2 インスタンスにポート 443 で受信トラフィックを許可する必要があります。このために、設定ファイルの `Resources` キーを使用して、AWSEBSecurityGroup の受信ルールにポート 443 のルールを追加します。
次の例は、`AWSEBSecurityGroup` セキュリティグループに受信ルールを追加して、単一インスタンス環境のセキュリティグループのすべてのトラフィック用にポート 443 を開きます。
**`.ebextensions/https-instance-securitygroup.config`**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
デフォルト [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/) (Amazon VPC) のロードバランシング環境では、ロードバランサーからのトラフィックのみを受け入れるように、このポリシーを変更できます。例については、「[負荷分散された Elastic Beanstalk 環境でエンドツーエンドの暗号化を設定する](configuring-https-endtoend.md)」を参照してください。
**Topics**
+ [
# Docker を実行している EC2 インスタンスでの HTTPS の終了
](https-singleinstance-docker.md)
+ [
# Go を実行している EC2 インスタンスでの HTTPS の終了
](https-singleinstance-go.md)
+ [
# Java SE を実行する EC2 インスタンスで HTTPS を終了する
](https-singleinstance-java.md)
+ [
# Node.js を実行している EC2 インスタンスで HTTPS を終了する
](https-singleinstance-nodejs.md)
+ [
# PHP を実行している EC2 インスタンスでの HTTPS の終了
](https-singleinstance-php.md)
+ [
# Python を実行している EC2 インスタンスの HTTPS を終了する
](https-singleinstance-python.md)
+ [
# Ruby を実行している EC2 インスタンスでの HTTPS の終了
](https-singleinstance-ruby.md)
+ [
# Tomcat を実行している EC2 インスタンスでの HTTPS の終了
](https-singleinstance-tomcat.md)
+ [
# .NET Core on Linux を実行している Amazon EC2 インスタンスでの HTTPS の終了
](https-singleinstance-dotnet-linux.md)
+ [
# .NET を実行している Amazon EC2 インスタンスでの HTTPS の終了
](SSLNET.SingleInstance.md)
# Docker を実行している EC2 インスタンスでの HTTPS の終了
Docker コンテナでは、[設定ファイル](ebextensions.md)を使用して HTTPS を有効にします。
次のスニペットを設定ファイルに追加して、証明書とプライベートキー資料を説明に沿って置き換え、ソースバンドルの `.ebextensions` ディレクトリに保存します。設定ファイルは以下のタスクを実行します。
+ `files` キーはインスタンスに次のファイルを作成します。
`/etc/nginx/conf.d/https.conf`
nginx サーバーを設定します。このファイルは、nginx サービスの開始時にロードされます。
`/etc/pki/tls/certs/server.crt`
インスタンスに証明書ファイルを作成します。*証明書ファイルの内容*をお客様の証明書の内容に置き換えます。
YAML は、一貫したインデントに依存します。設定ファイルの例でコンテンツを置き換える際はインデントレベルを一致させ、テキストエディタがインデントにタブ文字ではなくスペースを使用していることを確認します。
中間証明書がある場合は、`server.crt` のサイト証明書の後に組み込みます。
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
インスタンスにプライベートキーのファイルを作成します。*プライベートキーの内容*を、証明書リクエストまたは自己署名証明書の作成に使用したプライベートキーの内容に置き換えます。
**Example .ebextensions/https-instance.config**
```
files:
/etc/nginx/conf.d/https.conf:
mode: "000644"
owner: root
group: root
content: |
# HTTPS Server
server {
listen 443;
server_name localhost;
ssl on;
ssl_certificate /etc/pki/tls/certs/server.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://docker;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
/etc/pki/tls/certs/server.crt:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**注記**
プライベートキーを含む設定ファイルがソースコントロールにコミットされないようにしてください。設定をテストして動作が適切であることを確認したら、プライベートキーを Amazon S3 に保存して、デプロイ中にダウンロードされるように設定を変更します。手順については、「[秘密キーを Amazon S3 に安全に保存する](https-storingprivatekeys.md)」を参照してください。
単一インスタンスの環境では、インスタンスのセキュリティも変更してポート 443 のトラフィックを許可する必要があります。次の設定ファイルは、 CloudFormation [関数](ebextensions-functions.md)を使用してセキュリティグループの ID を取得し、それにルールを追加します。
**Example .ebextensions/https-instance-single.config**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
ロードバランシング環境では、エンドツーエンドの暗号化のために[安全なトラフィックを変更なしでパスする](https-tcp-passthrough.md)か[復号および暗号化する](configuring-https-endtoend.md)ことができるようにロードバランサーを設定します。
# Go を実行している EC2 インスタンスでの HTTPS の終了
Go コンテナタイプでは、[設定ファイル](ebextensions.md)と nginx 設定ファイルで HTTPS を有効にして、nginx サーバーが HTTPS を使用するように設定します。
次のスニペットを設定ファイルに追加して、証明書とプライベートキープレースホルダーを説明に沿って置き換え、ソースバンドルの `.ebextensions` ディレクトリに保存します。設定ファイルは以下のタスクを実行します。
+ `Resources` キーは、環境のインスタンスによって使用されるセキュリティグループでポート 443 を有効にします。
+ `files` キーはインスタンスに次のファイルを作成します。
`/etc/pki/tls/certs/server.crt`
インスタンスに証明書ファイルを作成します。*証明書ファイルの内容*をお客様の証明書の内容に置き換えます。
YAML は、一貫したインデントに依存します。設定ファイルの例でコンテンツを置き換える際はインデントレベルを一致させ、テキストエディタがインデントにタブ文字ではなくスペースを使用していることを確認します。
中間証明書がある場合は、`server.crt` のサイト証明書の後に組み込みます。
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
インスタンスにプライベートキーのファイルを作成します。*プライベートキーの内容*を、証明書リクエストまたは自己署名証明書の作成に使用したプライベートキーの内容に置き換えます。
**Example .ebextensions/https-instance.config**
```
files:
/etc/pki/tls/certs/server.crt:
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**注記**
プライベートキーを含む設定ファイルがソースコントロールにコミットされないようにしてください。設定をテストして動作が適切であることを確認したら、プライベートキーを Amazon S3 に保存して、デプロイ中にダウンロードされるように設定を変更します。手順については、「[秘密キーを Amazon S3 に安全に保存する](https-storingprivatekeys.md)」を参照してください。
ソースバンドルの `.conf` ディレクトリの `.ebextensions/nginx/conf.d/` 拡張子が付いたファイルに以下を格納します (たとえば、`.ebextensions/nginx/conf.d/https.conf`)。*app\$1port* を、アプリケーションがリッスンするポート番号に置き換えます。この例は、SSL を使用してポート番号 443 を使用するように nginx サーバーを設定しています。Go プラットフォームの設定ファイルについての詳細は、｢[プロキシサーバーを設定します](go-nginx.md)」を参照してください。
**Example .ebextensions/nginx/conf.d/https.conf**
```
# HTTPS server
server {
listen 443;
server_name localhost;
ssl on;
ssl_certificate /etc/pki/tls/certs/server.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://localhost:app_port;
proxy_set_header Connection "";
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
```
単一インスタンスの環境では、インスタンスのセキュリティも変更してポート 443 のトラフィックを許可する必要があります。次の設定ファイルは、 CloudFormation [関数](ebextensions-functions.md)を使用してセキュリティグループの ID を取得し、それにルールを追加します。
**Example .ebextensions/https-instance-single.config**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
ロードバランシング環境では、エンドツーエンドの暗号化のために[安全なトラフィックを変更なしでパスする](https-tcp-passthrough.md)か[復号および暗号化する](configuring-https-endtoend.md)ことができるようにロードバランサーを設定します。
# Java SE を実行する EC2 インスタンスで HTTPS を終了する
Java SE コンテナタイプでは、.ebextensions [設定ファイル](ebextensions.md)で HTTPS を有効にして、nginx 設定ファイルで HTTPS を使用するように nginx サーバーを設定します。
すべての AL2023/AL2 プラットフォームでは、統一されたプロキシ設定機能がサポートされています。AL2023/AL2 を実行中のプラットフォームバージョンでプロキシサーバーを設定する方法の詳細については、「[リバースプロキシの設定](platforms-linux-extend.proxy.md)」を参照してください。
次のスニペットを設定ファイルに追加して、証明書とプライベートキープレースホルダーを説明に沿って置き換え、`.ebextensions` ディレクトリに保存します。設定ファイルは以下のタスクを実行します。
+ `files` キーはインスタンスに次のファイルを作成します。
`/etc/pki/tls/certs/server.crt`
インスタンスに証明書ファイルを作成します。*証明書ファイルの内容*をお客様の証明書の内容に置き換えます。
YAML は、一貫したインデントに依存します。設定ファイルの例でコンテンツを置き換える際はインデントレベルを一致させ、テキストエディタがインデントにタブ文字ではなくスペースを使用していることを確認します。
中間証明書がある場合は、`server.crt` のサイト証明書の後に組み込みます。
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
インスタンスにプライベートキーのファイルを作成します。*プライベートキーの内容*を、証明書リクエストまたは自己署名証明書の作成に使用したプライベートキーの内容に置き換えます。
**Example .ebextensions/https-instance.config**
```
files:
/etc/pki/tls/certs/server.crt:
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**注記**
プライベートキーを含む設定ファイルがソースコントロールにコミットされないようにしてください。設定をテストして動作が適切であることを確認したら、プライベートキーを Amazon S3 に保存して、デプロイ中にダウンロードされるように設定を変更します。手順については、「[秘密キーを Amazon S3 に安全に保存する](https-storingprivatekeys.md)」を参照してください。
ソースバンドルの `.conf` ディレクトリの `.ebextensions/nginx/conf.d/` 拡張子が付いたファイルに以下を格納します (たとえば、`.ebextensions/nginx/conf.d/https.conf`)。*app\$1port* を、アプリケーションがリッスンするポート番号に置き換えます。この例は、SSL を使用してポート番号 443 を使用するように nginx サーバーを設定しています。Java SE プラットフォームの設定についての詳細は「[プロキシサーバーを設定します](java-se-nginx.md)」を参照してください。
**Example .ebextensions/nginx/conf.d/https.conf**
```
# HTTPS server
server {
listen 443;
server_name localhost;
ssl on;
ssl_certificate /etc/pki/tls/certs/server.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://localhost:app_port;
proxy_set_header Connection "";
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
```
単一インスタンスの環境では、インスタンスのセキュリティも変更してポート 443 のトラフィックを許可する必要があります。次の設定ファイルは、 CloudFormation [関数](ebextensions-functions.md)を使用してセキュリティグループの ID を取得し、それにルールを追加します。
**Example .ebextensions/https-instance-single.config**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
ロードバランシング環境では、エンドツーエンドの暗号化のために[安全なトラフィックを変更なしでパスする](https-tcp-passthrough.md)か[復号および暗号化する](configuring-https-endtoend.md)ことができるようにロードバランサーを設定します。
# Node.js を実行している EC2 インスタンスで HTTPS を終了する
次の設定ファイルの例では、[デフォルトの nginx 設定を拡張](nodejs-platform-proxy.md)して、ポート 443 をリッスンし、公開証明書とプライベートキーで SSL/TLS 接続を終了します。
[拡張ヘルスレポート](health-enhanced.md)の環境を設定した場合は、アクセスログを生成するように nginx を設定する必要があります。そのためには、先頭の `# For enhanced health...` 文字を削除して、`#` というコメントの下にある行のブロックをコメント解除します。
**Example .ebextensions/https-instance.config**
```
files:
/etc/nginx/conf.d/https.conf:
mode: "000644"
owner: root
group: root
content: |
# HTTPS server
server {
listen 443;
server_name localhost;
ssl on;
ssl_certificate /etc/pki/tls/certs/server.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
# For enhanced health reporting support, uncomment this block:
#if ($time_iso8601 ~ "^(\d{4})-(\d{2})-(\d{2})T(\d{2})") {
# set $year $1;
# set $month $2;
# set $day $3;
# set $hour $4;
#}
#access_log /var/log/nginx/healthd/application.log.$year-$month-$day-$hour healthd;
#access_log /var/log/nginx/access.log main;
location / {
proxy_pass http://nodejs;
proxy_set_header Connection "";
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
/etc/pki/tls/certs/server.crt:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
`files` キーはインスタンスに次のファイルを作成します。
`/etc/nginx/conf.d/https.conf`
nginx サーバーを設定します。このファイルは、nginx サービスの開始時にロードされます。
`/etc/pki/tls/certs/server.crt`
インスタンスに証明書ファイルを作成します。*証明書ファイルの内容*をお客様の証明書の内容に置き換えます。
YAML は、一貫したインデントに依存します。設定ファイルの例でコンテンツを置き換える際はインデントレベルを一致させ、テキストエディタがインデントにタブ文字ではなくスペースを使用していることを確認します。
中間証明書がある場合は、`server.crt` のサイト証明書の後に組み込みます。
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
インスタンスにプライベートキーのファイルを作成します。*プライベートキーの内容*を、証明書リクエストまたは自己署名証明書の作成に使用したプライベートキーの内容に置き換えます。
**注記**
プライベートキーを含む設定ファイルがソースコントロールにコミットされないようにしてください。設定をテストして動作が適切であることを確認したら、プライベートキーを Amazon S3 に保存して、デプロイ中にダウンロードされるように設定を変更します。手順については、「[秘密キーを Amazon S3 に安全に保存する](https-storingprivatekeys.md)」を参照してください。
単一インスタンスの環境では、インスタンスのセキュリティも変更してポート 443 のトラフィックを許可する必要があります。次の設定ファイルは、 CloudFormation [関数](ebextensions-functions.md)を使用してセキュリティグループの ID を取得し、それにルールを追加します。
**Example .ebextensions/https-instance-single.config**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
ロードバランシング環境では、エンドツーエンドの暗号化のために[安全なトラフィックを変更なしでパスする](https-tcp-passthrough.md)か[復号および暗号化する](configuring-https-endtoend.md)ことができるようにロードバランサーを設定します。
# PHP を実行している EC2 インスタンスでの HTTPS の終了
PHP コンテナタイプの場合、[設定ファイル](ebextensions.md)を使用して、Apache HTTP Server が HTTPS を使用できるようにします。
次のスニペットを設定ファイルに追加して、証明書とプライベートキー資料を説明に沿って置き換え、ソースバンドルの `.ebextensions` ディレクトリに保存します。
設定ファイルは以下のタスクを実行します。
+ `packages` キーは、yum を使用して `mod24_ssl` をインストールします。
+ `files` キーはインスタンスに次のファイルを作成します。
`/etc/httpd/conf.d/ssl.conf`
Apache サーバーを設定します。このファイルは、Apache サービスの開始時期をロードします。
`/etc/pki/tls/certs/server.crt`
インスタンスに証明書ファイルを作成します。*証明書ファイルの内容*をお客様の証明書の内容に置き換えます。
YAML は、一貫したインデントに依存します。設定ファイルの例でコンテンツを置き換える際はインデントレベルを一致させ、テキストエディタがインデントにタブ文字ではなくスペースを使用していることを確認します。
中間証明書がある場合は、`server.crt` のサイト証明書の後に組み込みます。
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
インスタンスにプライベートキーのファイルを作成します。*プライベートキーの内容*を、証明書リクエストまたは自己署名証明書の作成に使用したプライベートキーの内容に置き換えます。
**Example .ebextensions/https-instance.config**
```
packages:
yum:
mod24_ssl : []
files:
/etc/httpd/conf.d/ssl.conf:
mode: "000644"
owner: root
group: root
content: |
LoadModule ssl_module modules/mod_ssl.so
Listen 443
Order deny,allow
Allow from all
SSLEngine on
SSLCertificateFile "/etc/pki/tls/certs/server.crt"
SSLCertificateKeyFile "/etc/pki/tls/certs/server.key"
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLSessionTickets Off
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
ProxyPass / http://localhost:80/ retry=0
ProxyPassReverse / http://localhost:80/
ProxyPreserveHost on
RequestHeader set X-Forwarded-Proto "https" early
/etc/pki/tls/certs/server.crt:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**注記**
プライベートキーを含む設定ファイルがソースコントロールにコミットされないようにしてください。設定をテストして動作が適切であることを確認したら、プライベートキーを Amazon S3 に保存して、デプロイ中にダウンロードされるように設定を変更します。手順については、「[秘密キーを Amazon S3 に安全に保存する](https-storingprivatekeys.md)」を参照してください。
単一インスタンスの環境では、インスタンスのセキュリティも変更してポート 443 のトラフィックを許可する必要があります。次の設定ファイルは、 CloudFormation [関数](ebextensions-functions.md)を使用してセキュリティグループの ID を取得し、それにルールを追加します。
**Example .ebextensions/https-instance-single.config**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
ロードバランシング環境では、エンドツーエンドの暗号化のために[安全なトラフィックを変更なしでパスする](https-tcp-passthrough.md)か[復号および暗号化する](configuring-https-endtoend.md)ことができるようにロードバランサーを設定します。
# Python を実行している EC2 インスタンスの HTTPS を終了する
Web Server Gateway Interface (WSGI) で Apache HTTP Server を使用する Python コンテナタイプの場合、[設定ファイル](ebextensions.md)を使用して、Apache HTTP Server が HTTPS を使用できるようにします。
次のスニペットを[設定ファイル](ebextensions.md)に追加して、証明書とプライベートキーマテリアルを説明に従って置き換え、ソースバンドルの `.ebextensions` ディレクトリに保存します。設定ファイルは以下のタスクを実行します。
+ `packages` キーは、yum を使用して `mod_ssl` をインストールします。
+ `files` キーはインスタンスに次のファイルを作成します。
`/etc/httpd/conf.d/ssl.conf`
Apache サーバーを設定します。アプリケーションの名前が `application.py` でない場合は、`WSGIScriptAlias` の値内の強調表示されたテキストをそのアプリケーションへのローカルパスに置き換えてください。たとえば、django アプリケーションのものは `django/wsgi.py` にあることがあります。この場所は、お客様の環境用に設定した `WSGIPath` オプションの値と一致する必要があります。
アプリケーションの要件によっては、**python-path** パラメータに他のディレクトリを追加する必要もあります。
`/etc/pki/tls/certs/server.crt`
インスタンスに証明書ファイルを作成します。*証明書ファイルの内容*をお客様の証明書の内容に置き換えます。
YAML は、一貫したインデントに依存します。設定ファイルの例でコンテンツを置き換える際はインデントレベルを一致させ、テキストエディタがインデントにタブ文字ではなくスペースを使用していることを確認します。
中間証明書がある場合は、`server.crt` のサイト証明書の後に組み込みます。
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
インスタンスにプライベートキーのファイルを作成します。*プライベートキーの内容*を、証明書リクエストまたは自己署名証明書の作成に使用したプライベートキーの内容に置き換えます。
+ `container_commands` キーは、すべての設定が完了してから httpd サービスを停止し、httpd サービスが新しい `https.conf` ファイルと証明書を使用できるようにします。
**注記**
この例は、[Python](create-deploy-python-container.md) プラットフォームを使用する環境のみで動作します。
**Example .ebextensions/https-instance.config**
```
packages:
yum:
mod_ssl: []
files:
/etc/httpd/conf.d/ssl.conf:
mode: "000644"
owner: root
group: root
content: |
LoadModule wsgi_module modules/mod_wsgi.so
WSGIPythonHome /var/app/venv/staging-LQM1lest
WSGISocketPrefix run/wsgi
WSGIRestrictEmbedded On
Listen 443
SSLEngine on
SSLCertificateFile "/etc/pki/tls/certs/server.crt"
SSLCertificateKeyFile "/etc/pki/tls/certs/server.key"
Alias /static/ /var/app/current/static/
Order allow,deny
Allow from all
WSGIScriptAlias / /var/app/current/application.py
Require all granted
WSGIDaemonProcess wsgi-ssl processes=1 threads=15 display-name=%{GROUP} \
python-path=/var/app/current \
python-home=/var/app/venv/staging-LQM1lest \
home=/var/app/current \
user=webapp \
group=webapp
WSGIProcessGroup wsgi-ssl
/etc/pki/tls/certs/server.crt:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
container_commands:
01killhttpd:
command: "killall httpd"
02waitforhttpddeath:
command: "sleep 3"
```
**注記**
プライベートキーを含む設定ファイルがソースコントロールにコミットされないようにしてください。設定をテストして動作が適切であることを確認したら、プライベートキーを Amazon S3 に保存して、デプロイ中にダウンロードされるように設定を変更します。手順については、「[秘密キーを Amazon S3 に安全に保存する](https-storingprivatekeys.md)」を参照してください。
**Amazon Linux 2023 環境に関する注意事項**
Amazon Linux 2023 では、パッケージリポジトリで使用できないため、`mod_wsgi` を個別にインストールする必要があります。インストール手順については、PyPI の「[mod\$1wsgi](https://pypi.org/project/mod-wsgi/)」を参照してください。
単一インスタンスの環境では、インスタンスのセキュリティも変更してポート 443 のトラフィックを許可する必要があります。次の設定ファイルは、 CloudFormation [関数](ebextensions-functions.md)を使用してセキュリティグループの ID を取得し、それにルールを追加します。
**Example .ebextensions/https-instance-single.config**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
ロードバランシング環境では、エンドツーエンドの暗号化のために[安全なトラフィックを変更なしでパスする](https-tcp-passthrough.md)か[復号および暗号化する](configuring-https-endtoend.md)ことができるようにロードバランサーを設定します。
# Ruby を実行している EC2 インスタンスでの HTTPS の終了
Ruby コンテナタイプの場合、HTTPS を有効にする方法は使用するアプリケーションサーバーの種類によって異なります。
**Topics**
+ [
## Puma を使用する Ruby 用の HTTPS を設定する
](#Puma)
+ [
## Passenger を使用する Ruby 用の HTTPS を設定する
](#Passenger)
## Puma を使用する Ruby 用の HTTPS を設定する
アプリケーションサーバーとして Puma を使用する Ruby コンテナタイプの場合、[設定ファイル](ebextensions.md)を使用して HTTPS を有効にします。
次のスニペットを設定ファイルに追加して、証明書とプライベートキー資料を説明に沿って置き換え、ソースバンドルの `.ebextensions` ディレクトリに保存します。設定ファイルは以下のタスクを実行します。
+ `files` キーはインスタンスに次のファイルを作成します。
`/etc/nginx/conf.d/https.conf`
nginx サーバーを設定します。このファイルは、nginx サービスの開始時にロードされます。
`/etc/pki/tls/certs/server.crt`
インスタンスに証明書ファイルを作成します。*証明書ファイルの内容*をお客様の証明書の内容に置き換えます。
YAML は、一貫したインデントに依存します。設定ファイルの例でコンテンツを置き換える際はインデントレベルを一致させ、テキストエディタがインデントにタブ文字ではなくスペースを使用していることを確認します。
中間証明書がある場合は、`server.crt` のサイト証明書の後に組み込みます。
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
インスタンスにプライベートキーのファイルを作成します。*プライベートキーの内容*を、証明書リクエストまたは自己署名証明書の作成に使用したプライベートキーの内容に置き換えます。
**Example .ebextensions/https-instance.config**
```
files:
/etc/nginx/conf.d/https.conf:
content: |
# HTTPS server
server {
listen 443;
server_name localhost;
ssl on;
ssl_certificate /etc/pki/tls/certs/server.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://my_app;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
location /assets {
alias /var/app/current/public/assets;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
location /public {
alias /var/app/current/public;
gzip_static on;
gzip on;
expires max;
add_header Cache-Control public;
}
}
/etc/pki/tls/certs/server.crt:
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**注記**
プライベートキーを含む設定ファイルがソースコントロールにコミットされないようにしてください。設定をテストして動作が適切であることを確認したら、プライベートキーを Amazon S3 に保存して、デプロイ中にダウンロードされるように設定を変更します。手順については、「[秘密キーを Amazon S3 に安全に保存する](https-storingprivatekeys.md)」を参照してください。
単一インスタンスの環境では、インスタンスのセキュリティも変更してポート 443 のトラフィックを許可する必要があります。次の設定ファイルは、 CloudFormation [関数](ebextensions-functions.md)を使用してセキュリティグループの ID を取得し、それにルールを追加します。
**Example .ebextensions/https-instance-single.config**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
ロードバランシング環境では、エンドツーエンドの暗号化のために[安全なトラフィックを変更なしでパスする](https-tcp-passthrough.md)か[復号および暗号化する](configuring-https-endtoend.md)ことができるようにロードバランサーを設定します。
## Passenger を使用する Ruby 用の HTTPS を設定する
アプリケーションサーバーとして Passenger を使用する Ruby コンテナタイプの場合、設定ファイルと JSON ファイルの両方を使用してHTTPS を有効にします。
**Passenger を使用する Ruby 用の HTTPS を設定する方法**
1. 次のスニペットを設定ファイルに追加して、証明書とプライベートキー資料を説明に沿って置き換え、ソースバンドルの `.ebextensions` ディレクトリに保存します。設定ファイルは以下のタスクを実行します。
+ `files` キーはインスタンスに次のファイルを作成します。
`/etc/pki/tls/certs/server.crt`
インスタンスに証明書ファイルを作成します。*証明書ファイルの内容*をお客様の証明書の内容に置き換えます。
YAML は、一貫したインデントに依存します。設定ファイルの例でコンテンツを置き換える際はインデントレベルを一致させ、テキストエディタがインデントにタブ文字ではなくスペースを使用していることを確認します。
中間証明書がある場合は、`server.crt` のサイト証明書の後に組み込みます。
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
インスタンスにプライベートキーのファイルを作成します。*プライベートキーの内容*を、証明書リクエストまたは自己署名証明書の作成に使用したプライベートキーの内容に置き換えます。
**Example Passenger を使用する Ruby 用 HTTPS を設定するための .Ebextensions スニペット**
```
files:
/etc/pki/tls/certs/server.crt:
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**注記**
プライベートキーを含む設定ファイルがソースコントロールにコミットされないようにしてください。設定をテストして動作が適切であることを確認したら、プライベートキーを Amazon S3 に保存して、デプロイ中にダウンロードされるように設定を変更します。手順については、「[秘密キーを Amazon S3 に安全に保存する](https-storingprivatekeys.md)」を参照してください。
1. テキストファイルを作成して、ファイルに次の JSON を追加します。作成したファイルを、`passenger-standalone.json` という名前でソースバンドルのルートディレクトリに保存します。この JSON ファイルは、Passenger が HTTPS を使用するように設定します。
**重要**
この JSON ファイルには、バイト順マーク（BOM）が含まれてはいけません。BOM が含まれていると、Passenger JSON ライブラリはファイルを正しく読み取れず、Passenger サービスは開始されません。
**Example passenger-standalone.json**
```
{
"ssl" : true,
"ssl_port" : 443,
"ssl_certificate" : "/etc/pki/tls/certs/server.crt",
"ssl_certificate_key" : "/etc/pki/tls/certs/server.key"
}
```
単一インスタンスの環境では、インスタンスのセキュリティも変更してポート 443 のトラフィックを許可する必要があります。次の設定ファイルは、 CloudFormation [関数](ebextensions-functions.md)を使用してセキュリティグループの ID を取得し、それにルールを追加します。
**Example .ebextensions/https-instance-single.config**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
ロードバランシング環境では、エンドツーエンドの暗号化のために[安全なトラフィックを変更なしでパスする](https-tcp-passthrough.md)か[復号および暗号化する](configuring-https-endtoend.md)ことができるようにロードバランサーを設定します。
# Tomcat を実行している EC2 インスタンスでの HTTPS の終了
Tomcat コンテナタイプでは、[設定ファイル](ebextensions.md)を使用して、Tomcat 用のリバースプロキシとして機能する際に Apache HTTP サーバーが HTTPS を使用できるようにします。
次のスニペットを設定ファイルに追加して、証明書とプライベートキー資料を説明に沿って置き換え、ソースバンドルの `.ebextensions` ディレクトリに保存します。設定ファイルは以下のタスクを実行します。
+ `files` キーはインスタンスに次のファイルを作成します。
`/etc/pki/tls/certs/server.crt`
インスタンスに証明書ファイルを作成します。*証明書ファイルの内容*をお客様の証明書の内容に置き換えます。
YAML は、一貫したインデントに依存します。設定ファイルの例でコンテンツを置き換える際はインデントレベルを一致させ、テキストエディタがインデントにタブ文字ではなくスペースを使用していることを確認します。
`/etc/pki/tls/certs/server.key`
インスタンスにプライベートキーのファイルを作成します。*プライベートキーの内容*を、証明書リクエストまたは自己署名証明書の作成に使用したプライベートキーの内容に置き換えます。
`/opt/elasticbeanstalk/hooks/appdeploy/post/99_start_httpd.sh`
httpd サービスを再起動するためのデプロイメント後のフックスクリプトを作成します。
**Example .ebextensions/https-instance.config**
```
files:
/etc/pki/tls/certs/server.crt:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
/opt/elasticbeanstalk/hooks/appdeploy/post/99_start_httpd.sh:
mode: "000755"
owner: root
group: root
content: |
#!/usr/bin/env bash
sudo service httpd restart
```
ポート 443 をリッスンするように、環境のプロキシサーバーも設定する必要があります。次の Apache 2.4 設定では、ポート 443 にリスナーを追加します。詳細については、「[プロキシサーバーを設定します](java-tomcat-proxy.md)」を参照してください。
**Example .ebextensions/httpd/conf.d/ssl.conf**
```
Listen 443
ServerName server-name
SSLEngine on
SSLCertificateFile "/etc/pki/tls/certs/server.crt"
SSLCertificateKeyFile "/etc/pki/tls/certs/server.key"
Require all granted
ProxyPass / http://localhost:8080/ retry=0
ProxyPassReverse / http://localhost:8080/
ProxyPreserveHost on
ErrorLog /var/log/httpd/elasticbeanstalk-ssl-error_log
```
証明書ベンダーには、モバイルクライアントとの互換性向上のためにインストールできる中間証明書が含まれる場合があります。SSL 設定ファイルに以下を追加することで、中間認証局 (CA) バンドルを使用して Apache を設定します (場所については「[デフォルトの Apache 設定の拡張および上書き — Amazon Linux AMI (AL1)](java-tomcat-proxy.md#java-tomcat-proxy-apache)」を参照)。
+ `ssl.conf` ファイルコンテンツの場合、次の連鎖ファイルを指定:
```
SSLCertificateKeyFile "/etc/pki/tls/certs/server.key"
SSLCertificateChainFile "/etc/pki/tls/certs/gd_bundle.crt"
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
```
+ 中間証明書のコンテンツを使用して `files` キーに新しいエントリを追加します。
```
files:
/etc/pki/tls/certs/gd_bundle.crt:
mode: "000400"
owner: root
group: root
content: |
-----BEGIN CERTIFICATE-----
First intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Second intermediate certificate
-----END CERTIFICATE-----
```
**注記**
プライベートキーを含む設定ファイルがソースコントロールにコミットされないようにしてください。設定をテストして動作が適切であることを確認したら、プライベートキーを Amazon S3 に保存して、デプロイ中にダウンロードされるように設定を変更します。手順については、「[秘密キーを Amazon S3 に安全に保存する](https-storingprivatekeys.md)」を参照してください。
単一インスタンスの環境では、インスタンスのセキュリティも変更してポート 443 のトラフィックを許可する必要があります。次の設定ファイルは、 CloudFormation [関数](ebextensions-functions.md)を使用してセキュリティグループの ID を取得し、それにルールを追加します。
**Example .ebextensions/https-instance-single.config**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
ロードバランシング環境では、エンドツーエンドの暗号化のために[安全なトラフィックを変更なしでパスする](https-tcp-passthrough.md)か[復号および暗号化する](configuring-https-endtoend.md)ことができるようにロードバランサーを設定します。
# .NET Core on Linux を実行している Amazon EC2 インスタンスでの HTTPS の終了
.NET Core on Linux コンテナタイプでは、`.ebextensions`[設定ファイル](ebextensions.md)で HTTPS を有効にして、nginx 設定ファイルで HTTPS を使用するように nginx サーバーを設定します。
次のスニペットを設定ファイルに追加して、証明書とプライベートキープレースホルダーを説明に沿って置き換え、`.ebextensions` ディレクトリに保存します。設定ファイルは以下のタスクを実行します。
+ `files` キーはインスタンスに次のファイルを作成します。
`/etc/pki/tls/certs/server.crt`
インスタンスに証明書ファイルを作成します。*証明書ファイルの内容*をお客様の証明書の内容に置き換えます。
YAML は、一貫したインデントに依存します。設定ファイルの例でコンテンツを置き換える際はインデントレベルを一致させ、テキストエディタがインデントにタブ文字ではなくスペースを使用していることを確認します。
中間証明書がある場合は、`server.crt` のサイト証明書の後に組み込みます。
```
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
first intermediate certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
second intermediate certificate
-----END CERTIFICATE-----
```
`/etc/pki/tls/certs/server.key`
インスタンスにプライベートキーのファイルを作成します。*プライベートキーの内容*を、証明書リクエストまたは自己署名証明書の作成に使用したプライベートキーの内容に置き換えます。
**Example .ebextensions/https-instance.config**
```
files:
/etc/pki/tls/certs/server.crt:
content: |
-----BEGIN CERTIFICATE-----
certificate file contents
-----END CERTIFICATE-----
/etc/pki/tls/certs/server.key:
content: |
-----BEGIN RSA PRIVATE KEY-----
private key contents # See note below.
-----END RSA PRIVATE KEY-----
```
**注記**
プライベートキーを含む設定ファイルがソースコントロールにコミットされないようにしてください。設定をテストして動作が適切であることを確認したら、プライベートキーを Amazon S3 に保存して、デプロイ中にダウンロードされるように設定を変更します。手順については、「[秘密キーを Amazon S3 に安全に保存する](https-storingprivatekeys.md)」を参照してください。
ソースバンドルの `.conf` ディレクトリの `.platform/nginx/conf.d/` 拡張子が付いたファイルに以下を格納します (たとえば、`.platform/nginx/conf.d/https.conf`)。*app\$1port* を、アプリケーションがリッスンするポート番号に置き換えます。この例は、SSL を使用してポート番号 443 を使用するように nginx サーバーを設定しています。.NET Core on Linux プラットフォームの設定ファイルについての詳細は、「[プロキシサーバーを設定します](dotnet-linux-platform-nginx.md)」を参照してください。
**Example .platform/nginx/conf.d/https.conf**
```
# HTTPS server
server {
listen 443 ssl;
server_name localhost;
ssl_certificate /etc/pki/tls/certs/server.crt;
ssl_certificate_key /etc/pki/tls/certs/server.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
location / {
proxy_pass http://localhost:app_port;
proxy_set_header Connection "";
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}
```
単一インスタンスの環境では、インスタンスのセキュリティも変更してポート 443 のトラフィックを許可する必要があります。次の設定ファイルは、 CloudFormation [関数](ebextensions-functions.md)を使用してセキュリティグループの ID を取得し、それにルールを追加します。
**Example .ebextensions/https-instance-single.config**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
ロードバランシング環境では、エンドツーエンドの暗号化のために[安全なトラフィックを変更なしでパスする](https-tcp-passthrough.md)か[復号および暗号化する](configuring-https-endtoend.md)ことができるようにロードバランサーを設定します。
# .NET を実行している Amazon EC2 インスタンスでの HTTPS の終了
次の[設定ファイル](ebextensions.md)は、以下のタスクを実行する Windows PowerShell スクリプトを作成して実行します。
+ ポート 443 にバインドされる既存の HTTPS 証明書を確認する。
+ Amazon S3 バケットから、[PFX 証明書](configuring-https-ssl.md)とパスワードを取得する。
**注記**
Amazon S3 バケット内の SSL 証明書にアクセスするには、`AmazonS3ReadOnlyAccess` ポリシーを `aws-elasticbeanstalk-ec2-role` に追加します。
+ パスワードを から取得します AWS Secrets Manager。
**注記**
証明書パスワードを含むシークレットの `secretsmanager:GetSecretValue` アクションを許可するステートメントを `aws-elasticbeanstalk-ec2-role` に追加します
+ 証明書をインストールする。
+ ポート 443 に証明書をバインドする。
**注記**
HTTP エンドポイント (ポート 80) を削除するには、`Remove-WebBinding` コマンドをサンプルの「**HTTP バインディングを削除する**」セクションに含めます。
**Example .ebextensions/https-instance-dotnet.config**
```
files:
"C:\\certs\\install-cert.ps1":
content: |
import-module webadministration
## Settings - replace the following values with your own
$bucket = "amzn-s3-demo-bucket" ## S3 bucket name
$certkey = "example.com.pfx" ## S3 object key for your PFX certificate
$secretname = "example_secret" ## AWS Secrets Manager name for a secret that contains the certificate's password
##
# Set variables
$certfile = "C:\cert.pfx"
$pwd = Get-SECSecretValue -SecretId $secretname | select -expand SecretString
# Clean up existing binding
if ( Get-WebBinding "Default Web Site" -Port 443 ) {
Echo "Removing WebBinding"
Remove-WebBinding -Name "Default Web Site" -BindingInformation *:443:
}
if ( Get-Item -path IIS:\SslBindings\0.0.0.0!443 ) {
Echo "Deregistering WebBinding from IIS"
Remove-Item -path IIS:\SslBindings\0.0.0.0!443
}
# Download certificate from S3
Read-S3Object -BucketName $bucket -Key $certkey -File $certfile
# Install certificate
Echo "Installing cert..."
$securepwd = ConvertTo-SecureString -String $pwd -Force -AsPlainText
$cert = Import-PfxCertificate -FilePath $certfile cert:\localMachine\my -Password $securepwd
# Create site binding
Echo "Creating and registering WebBinding"
New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https
New-Item -path IIS:\SslBindings\0.0.0.0!443 -value $cert -Force
## Remove the HTTP binding
## (optional) Uncomment the following line to unbind port 80
# Remove-WebBinding -Name "Default Web Site" -BindingInformation *:80:
##
# Update firewall
netsh advfirewall firewall add rule name="Open port 443" protocol=TCP localport=443 action=allow dir=OUT
commands:
00_install_ssl:
command: powershell -NoProfile -ExecutionPolicy Bypass -file C:\\certs\\install-cert.ps1
```
単一インスタンスの環境では、インスタンスのセキュリティも変更してポート 443 のトラフィックを許可する必要があります。次の設定ファイルは、 CloudFormation [関数](ebextensions-functions.md)を使用してセキュリティグループの ID を取得し、それにルールを追加します。
**Example .ebextensions/https-instance-single.config**
```
Resources:
sslSecurityGroupIngress:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
CidrIp: 0.0.0.0/0
```
ロードバランシング環境では、エンドツーエンドの暗号化のために[安全なトラフィックを変更なしでパスする](https-tcp-passthrough.md)か[復号および暗号化する](configuring-https-endtoend.md)ことができるようにロードバランサーを設定します。
# 負荷分散された Elastic Beanstalk 環境でエンドツーエンドの暗号化を設定する
ロードバランサーでセキュアな接続を終了し、バックエンドへの接続には HTTP を使用することで十分なアプリケーションもあります。 AWS リソース間のネットワークトラフィックは、同じアカウントで実行中であっても、接続の一部ではないインスタンスがリッスンすることはできません。
ただし、厳格な外部規制を遵守する必要があるアプリケーションを開発している場合は、すべてのネットワーク接続をセキュリティで保護しなければならないことがあります。Elastic Beanstalk コンソールまたは[設定ファイル](ebextensions.md)を使用し、Elastic Beanstalk 環境のロードバランサーをバックエンドインスタンスに接続することで、これらの要件を満たすことができます。次の手順では、設定ファイルを使用します。
まだ追加していない場合は、まず、[ロードバランサーにセキュアリスナーを追加](configuring-https-elb.md)します。
環境にインスタンスを設定して、安全なポートでリッスンして HTTPS 接続を終端する必要もあります。設定はプラットフォームによって異なります。手順については「[インスタンスでの HTTPS 終端の設定](https-singleinstance.md)」を参照してください。[自己署名証明書](configuring-https-ssl.md)を EC2 インスタンスで問題なく使用できます。
次に、アプリケーションが使用するセキュリティポートで HTTPS を使用してトラフィックを転送するように、リスナーを設定します。環境で使用するロードバランサーのタイプに基づいて、次のいずれかの設定ファイルを使用します。
**`.ebextensions/https-reencrypt-clb.config`**
この設定ファイルは、Classic Load Balancer で使用します。ロードバランサーの設定に加えて、設定ファイルは、ポート 443 および HTTPS を使用するようにデフォルトのヘルスチェックを変更して、ロードバランサーが安全に接続できることを確実にします。
```
option_settings:
aws:elb:listener:443:
InstancePort: 443
InstanceProtocol: HTTPS
aws:elasticbeanstalk:application:
Application Healthcheck URL: HTTPS:443/
```
**`.ebextensions/https-reencrypt-alb.config`**
この設定ファイルは、Application Load Balancer で使用します。
```
option_settings:
aws:elbv2:listener:443:
DefaultProcess: https
ListenerEnabled: 'true'
Protocol: HTTPS
aws:elasticbeanstalk:environment:process:https:
Port: '443'
Protocol: HTTPS
```
**`.ebextensions/https-reencrypt-nlb.config`**
この設定ファイルは、Network Load Balancer で使用します。
```
option_settings:
aws:elbv2:listener:443:
DefaultProcess: https
ListenerEnabled: 'true'
aws:elasticbeanstalk:environment:process:https:
Port: '443'
```
`DefaultProcess`オプションの名前は、Application Load Balancer が特定のパスへのトラフィックについて同じポートにデフォルトでないリスナーを設定できることにちなんでいます (詳細については、「[Application Load Balancer](environments-cfg-alb.md)」を参照してください)。Network Load Balancer の場合、このオプションでは、このリスナーの唯一のターゲットプロセスを指定します。
この例では、セキュアな (HTTPS) トラフィックをリッスンするため、プロセスは `https` という名前になります。Network Load Balancer は TCP でのみ使用できるため、リスナーは、TCP プロトコルを使用して、指定ポートのプロセスにトラフィックを送信します。HTTP および HTTPS のネットワークトラフィックは TCP の上で実装されるため、これは問題ありません。
**注記**
EB CLI および Elastic Beanstalk コンソールでは、上記のオプションに推奨値が適用されます。設定ファイルを使用して同じファイルを設定する場合は、これらの設定を削除する必要があります。詳細については、「[推奨値](command-options.md#configuration-options-recommendedvalues)」を参照してください。
次のタスクでは、トラフィックを許可するようにロードバランサーのセキュリティグループを変更する必要があります。環境を起動する [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/) (Amazon VPC) (デフォルトの VPC またはカスタム VPC) によって、ロードバランサーのセキュリティグループが異なります。デフォルト VPC では、Elastic Load Balancing は、すべてのロードバランサーで使用できるデフォルトのセキュリティグループを提供します。カスタムの Amazon VPC では、ロードバランサーで使用するセキュリティグループが Elastic Beanstalk によって作成されます。
両方のシナリオをサポートするには、セキュリティグループを作成し、それを使用するように Elastic Beanstalk に指示することができます。次の設定ファイルは、セキュリティグループを作成して、ロードバランサーにアタッチします。
**`.ebextensions/https-lbsecuritygroup.config`**
```
option_settings:
# Use the custom security group for the load balancer
aws:elb:loadbalancer:
SecurityGroups: '`{ "Ref" : "loadbalancersg" }`'
ManagedSecurityGroup: '`{ "Ref" : "loadbalancersg" }`'
Resources:
loadbalancersg:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: load balancer security group
VpcId: vpc-########
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 443
ToPort: 443
CidrIp: 0.0.0.0/0
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 0.0.0.0/0
SecurityGroupEgress:
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 0.0.0.0/0
```
強調表示されたテキストをデフォルトまたはカスタム VPC ID に置き換えます。上記の例には、送受信にポート 80 を介して HTTP 接続を許可する設定が含まれています。安全な接続のみを許可する場合には、これらのプロパティを削除できます。
最後に、ロードバランサーのセキュリティグループとインスタンスのセキュリティグループ間でポート 443 経由の通信を許可する送受信ルールを追加します。
**`.ebextensions/https-backendsecurity.config`**
```
Resources:
# Add 443-inbound to instance security group (AWSEBSecurityGroup)
httpsFromLoadBalancerSG:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
SourceSecurityGroupId: {"Fn::GetAtt" : ["loadbalancersg", "GroupId"]}
# Add 443-outbound to load balancer security group (loadbalancersg)
httpsToBackendInstances:
Type: AWS::EC2::SecurityGroupEgress
Properties:
GroupId: {"Fn::GetAtt" : ["loadbalancersg", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
DestinationSecurityGroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
```
これをセキュリティグループの作成とは別に行うことで、循環依存を生じさせることなく、送信元および送信先のセキュリティグループを制限することができます。
上記のすべてのタスクを完了すると、ロードバランサーは HTTPS を使用してバックエンドインスタンスに安全に接続します。ロードバランサーは、インスタンスの証明書が信頼できる認証局によって発行されたものであるかどうかを確認しません。また、提供される証明書をすべて受け入れます。
特定の証明書のみを信頼するように指示するポリシーをロードバランサーに追加することで、この動作を変更できます。以下の設定ファイルは 2 つのポリシーを作成します。1 つのポリシーは公開証明書を指定し、もう 1 つは、インスタンスポート 443 への接続用の証明書のみを信頼するようにロードバランサーに指示します。
**`.ebextensions/https-backendauth.config`**
```
option_settings:
# Backend Encryption Policy
aws:elb:policies:backendencryption:
PublicKeyPolicyNames: backendkey
InstancePorts: 443
# Public Key Policy
aws:elb:policies:backendkey:
PublicKey: |
-----BEGIN CERTIFICATE-----
################################################################
################################################################
################################################################
################################################################
################################################
-----END CERTIFICATE-----
```
強調表示されたテキストを EC2 インスタンスの公開証明書の内容に置き換えます。
# 環境のロードバランサーを TCP パススルー用に設定する
AWS Elastic Beanstalk 環境内のロードバランサーで HTTPS トラフィックを復号しない場合は、バックエンドインスタンスへのリクエストをそのまま中継するようにセキュアリスナーを設定できます。
**重要**
復号せずに HTTPS トラフィックを中継するようにロードバランサーを設定することには、欠点があります。ロードバランサーが暗号化されたリクエストを見ることができないため、ルーティングを最適化したり、応答メトリクスをレポートしたりできません。
最初に[環境の EC2 インスタンスが HTTPS を終了するように設定](https-singleinstance.md)します。単一インスタンスの環境の設定をテストして、組み合わせにロードバランサーを追加する前に、すべてが機能していることを確認します。
[設定ファイル](ebextensions.md)をプロジェクトに追加して、TCP パケットをそのままバックエンドインスタンスのポート 443 に渡すように、ポート 443 のリスナーを設定します。
**`.ebextensions/https-lb-passthrough.config`**
```
option_settings:
aws:elb:listener:443:
ListenerProtocol: TCP
InstancePort: 443
InstanceProtocol: TCP
```
デフォルトの [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/) (Amazon VPC) では、インスタンスのセキュリティグループにルールを追加して、ロードバランサーから 443 への着信トラフィックを許可する操作も必要です。
**`.ebextensions/https-instance-securitygroup.config`**
```
Resources:
443inboundfromloadbalancer:
Type: AWS::EC2::SecurityGroupIngress
Properties:
GroupId: {"Fn::GetAtt" : ["AWSEBSecurityGroup", "GroupId"]}
IpProtocol: tcp
ToPort: 443
FromPort: 443
SourceSecurityGroupName: { "Fn::GetAtt": ["AWSEBLoadBalancer", "SourceSecurityGroup.GroupName"] }
```
カスタム VPC では、セキュリティグループ設定が Elastic Beanstalk によって更新されます。
# HTTP から HTTPS へのリダイレクトの設定
このトピックでは、アプリケーションへの HTTP トラフィックをエンドユーザーが開始した場合でも、処理する方法について説明します。これを行うには、*HTTP から HTTPS へのリダイレクト*を設定します。これは、*HTTPS の強制*と呼ばれることもあります。
リダイレクトを設定するには、まず、HTTPS トラフィックを処理するように環境を設定します。次に、HTTP トラフィックを HTTPS にリダイレクトします。これらの 2 つのステップについては、以下のサブセクションで説明します。
## HTTPS トラフィックを処理するように環境を設定する
環境の負荷分散設定に応じて、以下のいずれかの操作を行います。
+ **負荷分散された環境** – [HTTPS を終了するようにロードバランサーを設定します](configuring-https-elb.md)。
+ **単一インスタンス環境** – [インスタンスで HTTPS 接続を終了するようにアプリケーションを設定します](https-singleinstance.md)。この設定は、環境のプラットフォームによって異なります。
## HTTP トラフィックを HTTPS にリダイレクトする
アプリケーションの HTTP トラフィックを HTTPS にリダイレクトするには、環境のインスタンスのウェブサーバーまたは環境の Application Load Balancer を設定します。
**インスタンスウェブサーバーを設定する**
この方法は、任意のウェブサーバー環境で機能します。HTTP リダイレクトレスポンスステータスで HTTP トラフィックに応答するように、Amazon EC2 インスタンスのウェブサーバーを設定します。
この設定は、環境のプラットフォームによって異なります。GitHub の [https://github.com/awsdocs/elastic-beanstalk-samples/tree/master/configuration-files/aws-provided/security-configuration/https-redirect](https://github.com/awsdocs/elastic-beanstalk-samples/tree/master/configuration-files/aws-provided/security-configuration/https-redirect) コレクションでプラットフォームのフォルダを探して、そのフォルダ内のサンプル設定ファイルを使用します。
環境で [Elastic Load Balancing ヘルスチェック](using-features.healthstatus.md#using-features.healthstatus.understanding)を使用している場合、ロードバランサーは、正常なインスタンスが HTTP ヘルスチェックメッセージに HTTP 200 (OK) で応答することを想定します。したがって、ウェブサーバーはこれらのメッセージを HTTPS にリダイレクトすべきではありません。[https://github.com/awsdocs/elastic-beanstalk-samples/tree/master/configuration-files/aws-provided/security-configuration/https-redirect](https://github.com/awsdocs/elastic-beanstalk-samples/tree/master/configuration-files/aws-provided/security-configuration/https-redirect) のサンプル設定ファイルでは、この要件が正しく処理されています。
**ロードバランサーを設定する**
この方法は、[Application Load Balancer](environments-cfg-alb.md) を使用するロードバランスされた環境がある場合に機能します。Application Load Balancer は、HTTP トラフィックの受信時にリダイレクトレスポンスを送信できます。この場合、環境のインスタンスでリダイレクトを設定する必要はありません。
GitHub には、リダイレクト用に Application Load Balancer を設定する方法を示す 2 つのサンプル設定ファイルがあります。
+ [https://github.com/awsdocs/elastic-beanstalk-samples/blob/master/configuration-files/aws-provided/resource-configuration/alb-http-to-https-redirection-full.config](https://github.com/awsdocs/elastic-beanstalk-samples/blob/master/configuration-files/aws-provided/resource-configuration/alb-http-to-https-redirection-full.config) 設定ファイルでは、ポート 443 で HTTPS リスナーを作成し、受信 HTTP トラフィックを HTTPS にリダイレクトするようにデフォルトのポート 80 リスナーを変更します。
+ [https://github.com/awsdocs/elastic-beanstalk-samples/blob/master/configuration-files/aws-provided/resource-configuration/alb-http-to-https-redirection.config](https://github.com/awsdocs/elastic-beanstalk-samples/blob/master/configuration-files/aws-provided/resource-configuration/alb-http-to-https-redirection.config) 設定ファイルでは、443 リスナーが定義されることが想定されています。これを定義するには、標準の Elastic Beanstalk 設定名前空間、または Elastic Beanstalk コンソールを使用できます。次に、ポート 80 リスナーをリダイレクト用に変更します。