翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Application Load Balancer での TLS による相互認証
相互 TLS 認証は、Transport Layer Security (TLS) のバリエーションの 1 つです。従来の TLS はサーバーとクライアント間の安全な通信を確立するもので、サーバーはクライアントに自身の ID を提供する必要がありました。相互 TLS では、ロードバランサーが TLS のネゴシエート中にクライアントとサーバー間の相互認証をネゴシエートします。Application Load Balancer で相互 TLS を使用すると、認証管理が簡素化されアプリケーションの負荷が軽減されます。
相互 TLS を使用することで、ロードバランサーはクライアント認証を管理して、信頼できるクライアントのみにバックエンドアプリケーションと通信させることができます。この機能を使用すると、ロードバランサーは、サードパーティー認証機関 (CA) の証明書を使用するか、オプションで失効チェックで AWS Private Certificate Authority (PCA) を使用してクライアントを認証します。ロードバランサーはクライアント証明書情報を HTTP ヘッダーを使用してバックエンドに渡し、アプリケーションはこれを認証に使用できます。
Application Load Balancer の相互 TLS には、X.509v3 クライアント証明書を検証するための次の方法があります。
+ **相互 TLS パススルー:** ロードバランサーは、クライアント証明書チェーン全体を検証せずにターゲットに送信します。ターゲットはクライアント証明書チェーンを検証する必要があります。次に、このクライアント証明書チェーンを使用して、ロードバランサー認証とターゲット認証のロジックをアプリケーションに実装できます。
+ **相互 TLS 検証:** ロードバランサーは、ロードバランサーが TLS 接続をネゴシエートするときに、クライアントに対して X.509 クライアント証明書認証を実行します。
相互 TLS パススルーを使用するには、クライアントからの証明書を受け入れるようにリスナーを設定する必要があります。検証で相互 TLS を使用するには、「[Application Load Balancer での相互 TLS の設定](configuring-mtls-with-elb.md)」を参照してください。
## Application Load Balancer で相互 TLS の設定を開始する前に
Application Load Balancer で相互 TLS の設定を開始するときは、以下の点に注意します。
**クォータ**
Application Load Balancer には、 AWS アカウント内で使用されているトラストストア、CA 証明書、および証明書失効リストの量に関連する特定の制限が含まれます。
詳細については、「[Quotas for your Application Load Balancers](load-balancer-limits.md)」を参照してください。
**証明書の要件**
Application Load Balancer は、相互 TLS 認証で使用される証明書に対して以下をサポートしています。
+ サポートされている証明書: X.509v3
+ サポートされているパブリックキー: RSA 2K – 8K または ECDSA secp256r1、secp384r1、secp521r1
+ サポートされている署名アルゴリズム: SHA256、384、512 with RSA/SHA256、384、512 with EC/SHA256、384、512 hash with RSASSA-PSS with MGF1
**CA 証明書のバンドル**
以下は、認証局 (CA) バンドルに適用されます。
+ Application Load Balancer は、各認証局 (CA) 証明書バンドルをバッチでアップロードします。Application Load Balancer は、個々の証明書のアップロードはサポートしていません。新しい証明書を追加する必要がある場合は、証明書のバンドルファイルをアップロードする必要があります。
+ CA 証明書バンドルを置き換えるには、[ModifyTrustStore](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ModifyTrustStore.html) API を使用します。
**パススルーの証明書の順序**
相互 TLS パススルーを使用するときは、Application Load Balancer がヘッダーを挿入してクライアント証明書チェーンをバックエンドのターゲットに提示します。プレゼンテーションの順序は、リーフ証明書から始まりルート証明書で終わります。
**セッションの再開**
Application Load Balancer で相互 TLS パススルーまたは検証モードを使用している間は、セッションの再開はサポートされません。
**HTTP ヘッダー**
Application Load Balancer は、相互 TLS を使用してクライアント接続をネゴシエートするときは `X-Amzn-Mtls` ヘッダーを使用して証明書情報を送信します。詳細およびヘッダーの例については、「[HTTP ヘッダーと相互 TLS](#mtls-http-headers)」を参照してください。
**CA 証明書ファイル**
CA 証明書ファイルは以下の要件を満たす必要があります。
+ 証明書ファイルは PEM (Privacy Enhanced Mail) 形式を使用する。
+ 証明書の中身は `-----BEGIN CERTIFICATE-----` と `-----END CERTIFICATE-----` の境界で囲む。
+ コメントは先頭に `#` を付け、`-` を含めない。
+ 空白の行は使用できない。
受け入れられない証明書の例 (無効):
```
# comments
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 01
Signature Algorithm: ecdsa-with-SHA384
Issuer: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE
Validity
Not Before: Jan 11 23:57:57 2024 GMT
Not After : Jan 10 00:57:57 2029 GMT
Subject: C=US, O=EXAMPLE, OU=EXAMPLE, CN=EXAMPLE
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (384 bit)
pub:
00:01:02:03:04:05:06:07:08
ASN1 OID: secp384r1
NIST CURVE: P-384
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
00:01:02:03:04:05:06:07:08
X509v3 Subject Alternative Name:
URI:EXAMPLE.COM
Signature Algorithm: ecdsa-with-SHA384
00:01:02:03:04:05:06:07:08
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----
```
受け入れられる証明書の例 (有効):
1. 単一の証明書 (PEM エンコード):
```
# comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----
```
1. 複数の証明書 (PEM エンコード):
```
# comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----
# comments
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64–encoded certificate
-----END CERTIFICATE-----
```
## HTTP ヘッダーと相互 TLS
このセクションでは、相互 TLS を使用してクライアントとの接続をネゴシエートするときに、Application Load Balancer が証明書情報を送信するために使用する HTTP ヘッダーについて説明します。Application Load Balancer が使用する特定の `X-Amzn-Mtls` ヘッダーは、ユーザーが指定した相互 TLS モードがパススルーモードか検証モードかによって変わります。
Application Load Balancer でサポートされている他の HTTP ヘッダーについては、「[HTTP ヘッダーと Application Load Balancer](x-forwarded-headers.md)」を参照してください。
### パススルーモードの HTTP ヘッダー
パススルーモードの相互 TLS の場合、Application Load Balancer は次のヘッダーを使用します。
#### X-Amzn-Mtls-Clientcert
このヘッダーには、接続に表示されるクライアント証明書チェーン全体の、URL エンコードされた PEM 形式が、安全な文字 `+=/` として含まれています。
**ヘッダーのコンテンツ例:**
```
X-Amzn-Mtls-Clientcert: -----BEGIN%20CERTIFICATE-----%0AMIID<...reduced...>do0g%3D%3D%0A-----END%20CERTIFICATE-----%0A-----BEGIN%20CERTIFICATE-----%0AMIID1<...reduced...>3eZlyKA%3D%3D%0A-----END%20CERTIFICATE-----%0A
```
### 検証モードの HTTP ヘッダー
検証モードの相互 TLS の場合、Application Load Balancer は次のヘッダーを使用します。
#### X-Amzn-Mtls-Clientcert-Serial-Number
このヘッダーには、リーフ証明書のシリアル番号の 16 進数表現が含まれています。
**ヘッダーのコンテンツ例:**
```
X-Amzn-Mtls-Clientcert-Serial-Number: 03A5B1
```
#### X-Amzn-Mtls-Clientcert-Issuer
このヘッダーには、発行者の識別名 (DN) の RFC2253 文字列表現が含まれています。
**ヘッダーのコンテンツ例:**
```
X-Amzn-Mtls-Clientcert-Issuer: CN=rootcamtls.com,OU=rootCA,O=mTLS,L=Seattle,ST=Washington,C=US
```
#### X-Amzn-Mtls-Clientcert-Subject
このヘッダーには、サブジェクトの識別名 (DN) の RFC2253 文字列表現が含まれています。
**ヘッダーのコンテンツ例:**
```
X-Amzn-Mtls-Clientcert-Subject: CN=client_.com,OU=client-3,O=mTLS,ST=Washington,C=US
```
#### X-Amzn-Mtls-Clientcert-Validity
このヘッダーには、`notBefore` と `notAfter` 日付の ISO8601 形式が含まれています。
**ヘッダーのコンテンツ例:**
```
X-Amzn-Mtls-Clientcert-Validity: NotBefore=2023-09-21T01:50:17Z;NotAfter=2024-09-20T01:50:17Z
```
#### X-Amzn-Mtls-Clientcert-Leaf
このヘッダーには、リーフ証明書の URL エンコードされた PEM 形式が含まれ、`+=/` は安全な文字列として使用されています。
**ヘッダーのコンテンツ例:**
```
X-Amzn-Mtls-Clientcert-Leaf: -----BEGIN%20CERTIFICATE-----%0AMIIG<...reduced...>NmrUlw%0A-----END%20CERTIFICATE-----%0A
```
## 認証局 (CA) のサブジェクト名をアドバタイズする
認証局 (CA) のサブジェクト名をアドバタイズすると、相互 TLS 認証中に受け入れられる証明書をクライアントが判断できるようにすることで、認証プロセスが強化されます。
CA サブジェクト名のアドバタイズを有効にすると、Application Load Balancer は、関連付けられている信頼ストアに基づいて、信頼する認証局 (CA) サブジェクト名のリストをアドバタイズします。クライアントが Application Load Balancer を介してターゲットに接続すると、クライアントは信頼できる CA サブジェクト名のリストを受け取ります。
TLS ハンドシェイク中、Application Load Balancer がクライアント証明書をリクエストすると、証明書リクエストメッセージに信頼された CA 識別名 (DN) のリストが含まれます。これにより、クライアントはアドバタイズされた CA サブジェクト名に一致する有効な証明書を選択し、認証プロセスを合理化して接続エラーを減らすことができます。
新規および既存のリスナーで、広告 CA サブジェクト名を有効にできます。詳細については、「[HTTPS リスナーの追加](create-https-listener.md#add-https-listener)」を参照してください。
## Application Load Balancer の接続ログ
Elastic Load Balancing には、Application Load Balancer に送信されたリクエストに関する属性をキャプチャする、接続ログがあります。接続ログには、クライアントの IP アドレスとポート、クライアント証明書情報、接続結果、使用されている TLS 暗号などの情報が含まれています。これらの接続ログは、リクエストパターンやその他の傾向の確認に使用できます。
接続ログの詳細については、「[Application Load Balancer の接続ログ](load-balancer-connection-logs.md)」を参照してください。