相互 TLS（mTLS）は、クライアントとサーバーの間で相互認証を行うための業界標準プロトコルです。これにより、クライアントとサーバーの両方が、信頼できる認証局（CA）によって発行された有効な証明書を保持していることを確認することで、相互に認証されます。サーバーのみが認証される標準 TLS とは異なり、mTLS では、クライアントとサーバーの両方が証明書を提示し、通信を確立する前に両方の ID を確認する必要があります。
mTLS は、次のすべてのアプリケーション ロードバランサのターゲット HTTPS プロキシ リソースで構成されています。
- グローバル外部アプリケーション ロードバランサ
- 従来のアプリケーション ロードバランサ
- リージョン外部アプリケーション ロードバランサ
- リージョン内部アプリケーション ロードバランサ
- クロスリージョン内部アプリケーション ロードバランサ
mTLS は、公開鍵基盤（PKI）を使用して、ネットワーク経由で通信するエンティティの ID を認証します。このインフラストラクチャには、クライアント、サーバー、認証局（CA）の 3 つのコンポーネントが含まれています。ロードバランサの mTLS は、次の機能をサポートしています。
証明書を提示したクライアントが秘密鍵を所有していることを確認します。
クライアント証明書を次のいずれかのモードで検証します。
無効な証明書を拒否する: クライアント証明書チェーンを検証できない場合、リクエストを拒否して厳格な認証を適用します。
無効な証明書または存在しない証明書を許可する: クライアント証明書が欠落しているか無効であっても、すべてのリクエストをバックエンドに渡すことで柔軟性を提供します。
アップロードされた PKI アンカー（ルート証明書）に対してクライアント証明書を検証します。複数のアンカーを個別に追加して、ダウンタイムなしで古い PKI から新しい PKI にシームレスに移行できます。
指定した PKI アンカー（ルート証明書）に対するクライアント証明書検証パスの構築に役立つ中間証明書を指定します。これらの中間証明書を使用すると、完全な証明書チェーンを提供しないクライアントでも mTLS を使用できます。
証明書のフィンガープリントを生成し、カスタム リクエスト ヘッダーとしてバックエンドに渡します。
カスタム ヘッダーを使用して、証明書から抽出した特定のフィールドをバックエンドに渡します。
カスタム ヘッダーを使用して、検証結果と検証エラーをバックエンドに渡します。
証明書の要件
mTLS の証明書を構成する場合は、次の要件を満たしている必要があります。
- mTLS 認証の基盤となるのは最新の暗号化ツールです。証明書では、鍵交換に RSA または ECDSA アルゴリズムを使用する必要があります。ハッシュ化アルゴリズムでは、SHA-256 またはより強力な暗号ハッシュ関数を使用する必要があります。MD4、MD5、SHA-1 などのハッシュ化アルゴリズムはサポートされていません。
- クライアント（リーフ）証明書の場合:
- ルート証明書と中間証明書の場合:
mTLS デプロイのアーキテクチャ
mTLS を使用すると、トラストストアを含む信頼構成リソースを構成できます。トラストストアは、トラスト アンカー（ルート証明書）と、必要に応じて 1 つ以上の中間証明書をカプセル化します。ロードバランサは、クライアント証明書を受信すると、クライアント証明書から構成済みのトラスト アンカーまでの信頼チェーンを確立して、証明書を検証します。
ロードバランサに mTLS を設定する際に構成する必要があるさまざまなリソースの概要は次のとおりです。
信頼構成。単一のトラストストア リソースが含まれており、そのトラストストアがトラスト アンカー（ルート証明書）をカプセル化します。また、必要に応じて 1 つ以上の中間証明書をカプセル化します。信頼構成は、クライアント証明書とトラスト アンカーの間に信頼チェーンを確立するために使用されます。詳細については、信頼構成をご覧ください。
自己署名された証明書、期限切れの証明書、その他の無効な証明書を使用する必要がある場合、またはルート証明書と中間証明書にアクセスできない場合は、その証明書を
allowlistedCertificatesフィールドの信頼構成に追加することもできます。証明書を許可リストに追加するためにトラストストアは必要ありません。証明書を許可リストに追加すると、証明書が解析可能で、秘密鍵の所有の証明が確立され、証明書の SAN フィールドの制約が満たされている限り、証明書は常に有効とみなされます。
トラストストア。信頼チェーンの確立とクライアント証明書の検証に使用されるトラスト アンカーと中間認証局（CA）の証明書が含まれます。CA は、クライアントに信頼できる証明書を発行するために使用されます。CA は、ロードバランサのトラスト アンカー（ルート証明書）または中間 CA 証明書で識別されます。
トラストストアには、次の種類のルート証明書と中間証明書をアップロードできます。
- 任意の第三者の CA が発行した証明書。
- ユーザーの管理でプライベート CA が発行した証明書（プライベート CA による相互 TLS を設定するを参照）。
- ユーザー指定の証明書（ユーザー指定の証明書による相互 TLS を設定するを参照）。
クライアント認証（
ServerTLSPolicyとも呼ばれます）。クライアント証明書の検証で使用するクライアント検証モードと信頼構成リソースを指定します。クライアントがロードバランサに無効な証明書を提示するか、証明書を提示しない場合は、クライアント検証モードでクライアント接続の処理方法を指定します。mTLS 認証に関連するすべてのパラメータをサーバー TLS ポリシーで指定できます。クライアント認証（ServerTLSPolicy）リソースがターゲット HTTPS プロキシ リソースに接続されています。
次の図は、グローバル アプリケーション ロードバランサとリージョン アプリケーション ロードバランサのターゲット HTTPS プロキシ リソースに接続されているさまざまな mTLS コンポーネントを示しています。
グローバル
次の図は、外部アプリケーション ロードバランサのデプロイのコンポーネントを示しています。このアーキテクチャは、クロスリージョン内部アプリケーション ロードバランサ（グローバル コンポーネントを使用する内部アプリケーション ロードバランサ）にも適用されます。
リージョン
次の図は、リージョン内部アプリケーション ロードバランサのデプロイのコンポーネントを示しています。このアーキテクチャは、リージョン外部アプリケーション ロードバランサ（リージョン コンポーネントを使用する外部アプリケーション ロードバランサ）にも適用されます。
クライアント検証モード
クライアントがロードバランサに無効な証明書を提示するか、証明書を提示しない場合は、クライアント認証（ServerTLSPolicy）リソースの clientValidationMode 属性により、ロードバランサがクライアント接続を処理する方法が決まります。
クライアント検証モードの値は次のとおりです。
ALLOW_INVALID_OR_MISSING_CLIENT_CERT。クライアント証明書の証明書の検証が失敗した場合や、クライアント証明書が提示されていない場合でも、クライアントからの接続が許可されます。このモードでは、ロードバランサはクライアントからの接続を許可し、信頼チェーンを確立できるかどうかに関係なく、すべてのリクエストをバックエンドに渡します。クライアント証明書が提供されたときに、秘密鍵の所有者証明が常にチェックされます。クライアントが秘密鍵を所有していることを証明できない場合は、クライアント検証モードで無効なクライアント証明書やクライアント証明書の欠落が許可されている場合でも、TLS handshake は終了します。
REJECT_INVALID。クライアントが証明書を提供しない場合、または証明書の検証で不合格だった場合に接続を拒否します。このモードでは、クライアント証明書からトラスト アンカーへの信頼チェーンを確立できない場合、ロードバランサはクライアントからの接続を終了します。
ロードバランサで mTLS を構成する
ロードバランサで mTLS を構成するために必要な主な手順は次のとおりです。
トラスト アンカー（ルート証明書）とルート オブ トラストとして機能する中間証明書を含む信頼構成リソースを作成します。
信頼構成をクライアント認証（
ServerTLSPolicy）リソースにリンクします。これにより、クライアント検証モード（ALLOW_INVALID_OR_MISSING_CLIENT_CERTまたはREJECT_INVALID）が定義されます。クライアント認証（
ServerTLSPolicy）リソースをロードバランサのターゲット HTTPS プロキシ リソースに接続します。省略可: カスタム mTLS ヘッダーを使用して、mTLS 接続に関する情報をバックエンド サービスまたは URL マップに渡すことができます。
この設定の詳細については、次のガイドをご覧ください。
クライアント証明書の検証手順
ロードバランサは、クライアント証明書を検証するときに次の処理を行います。
クライアントが秘密鍵を所有していることを確認する。
クライアントは、handshake プロセス中に署名を生成することで、証明書の公開鍵に関連付けられた秘密鍵を保持していることを証明します。ロードバランサは、クライアントの公開鍵を使用してこの署名を検証します。署名の検証に失敗した場合、クライアントが証明書の所有者ではないことを意味します。この場合、構成で無効なクライアント証明書やクライアント証明書の欠落が許可されている場合でも、TLS handshake は終了します。グローバル外部アプリケーション ロードバランサではエラーはロギングされませんが、リージョン外部アプリケーション ロードバランサと内部アプリケーション ロードバランサの
proxyStatusフィールドに TLS エラーがロギングされます。信頼チェーンを検証する。
ロードバランサは、クライアント証明書と構成済みの信頼構成間の信頼チェーンを検証します。次のことが検証されます。
- クライアント、中間証明書、ルート証明書が証明書の要件を満たしている。
- 親証明書のサブジェクト フィールドが子証明書の発行元フィールドと一致している。この検証により、親証明書の ID（サブジェクト）が、子証明書の発行者としてリストされている ID と一致することが確認されます。
- 親証明書のサブジェクト鍵 ID（SKID）が子証明書の認証機関鍵 ID（AKID）と一致している。この一致は、子証明書が正しいルート認証局によって発行されており、証明書の有効性を検証するために AKID でルートの公開鍵が参照されているため、信頼できることを意味します。
- 子証明書のサブジェクト代替名（SAN）が親証明書の
NameConstraintsフィールドに違反していない。
リクエストをバックエンドに転送する。
クライアント証明書の検証が成功すると、リクエストはカスタム mTLS ヘッダーを使用してバックエンドに転送されます。
ただし、検証が失敗した場合、実行されるアクションはクライアント検証モードの値によって異なります。
ALLOW_INVALID_OR_MISSING_CLIENT_CERT: 検証が失敗した理由を示すカスタム mTLS ヘッダーとともにリクエストが転送されます。クロスリージョン内部アプリケーション ロードバランサ、リージョン外部アプリケーション ロードバランサ、またはリージョン内部アプリケーション ロードバランサの場合は、カスタム mTLS ヘッダーに加えて mTLS オプション フィールドを構成して、失敗の理由を確認できます。REJECT_INVALID: 接続が終了し、エラーが Cloud Logging に記録されます。
バックエンドに渡されるカスタム mTLS ヘッダー
次の表に、クライアント証明書が検証に合格した場合と失敗した場合の両方でバックエンドに渡されるカスタム mTLS ヘッダーを示します。クライアント証明書の検証に失敗したときに、クライアント検証モードが ALLOW_INVALID_OR_MISSING_CLIENT_CERT に設定されている場合にのみ、カスタム ヘッダーがバックエンドに渡されます。
| クライアント証明書のステータス | クライアント検証モード | カスタム ヘッダー |
|---|---|---|
クライアント証明書チェーンが長すぎる（クライアント証明書に 10 を超える中間証明書が含まれる）。 |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
クライアントまたは中間証明書の RSA 鍵のサイズが無効。 検証は実行されません。 RSA 鍵の長さは 2,048～4,096 ビットです。 |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
クライアント証明書または中間証明書が、サポートされていない楕円曲線を使用している。 検証は実行されません。 有効な楕円曲線は P-256 と P-384 です。 |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
クライアント証明書または中間証明書が、RSA 以外、ECDSA 以外のアルゴリズムを使用している。 検証は実行されません。 |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
検証に使用する PKI に、同じサブジェクトとサブジェクトの公開鍵情報を共有する 11 個以上の中間証明書がある。 検証は実行されません。 |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
検証に指定された中間証明書に 10 を超える名前の制約がある。 |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
クライアント証明書に、 |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
| 証明書チェーンの検証中に制限時間を超過した。 | ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
client_cert_sha256_fingerprint: <cert hash>
|
証明書チェーンの検証中に、深度または反復処理の上限に達した。 証明書チェーンの最大深度は、ルート証明書とクライアント証明書を含めて 10 です。反復処理の最大回数は 100（クライアント証明書チェーンの検証のために確認される証明書）です。 |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
検証は実行できませんが、証明書ハッシュはバックエンドに転送されます。 |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
| クライアント証明書がない。 | ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
クライアント証明書で TrustConfig リソースに対する検証に失敗した。 |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
| クライアント証明書で証明書確認検証に合格した。 | 該当なし |
client_cert_error: <empty>
|
エラー処理とロギング
アプリケーション ロードバランサには、クライアント証明書の検証のモニタリング、潜在的な問題の特定、接続の問題のトラブルシューティングを可能にする詳細なロギング機能が用意されています。このセクションでは、mTLS 検証中に発生する可能性のあるさまざまなタイプのエラーと、それらのエラーのロギング方法について説明します。
REJECT_INVALID モードでログに記録されたエラー
クライアント証明書の検証が失敗し、クライアント検証モードが REJECT_INVALID に設定されている場合、接続は終了し、エラーが Cloud Logging にロギングされます。次の表で、これらのエラーについて説明します。
| クライアント証明書のステータス | ロギングされたエラー |
|---|---|
| クライアント証明書チェーンが長すぎる（クライアント証明書に 10 を超える中間証明書が含まれる）。 |
client_cert_chain_exceeded_limit
|
クライアントまたは中間証明書の RSA 鍵のサイズが無効。 検証は実行されません。 RSA 鍵の長さは 2,048～4,096 ビットです。 |
client_cert_invalid_rsa_key_size
|
クライアント証明書または中間証明書で、サポートされていない楕円曲線が使用されています。 検証は実行されません。 有効な曲線は P-256 と P-384 です。 |
client_cert_unsupported_elliptic_curve_key
|
クライアント証明書または中間証明書が、非 RSA または ECDSA 以外のアルゴリズムを使用しています。 検証は実行されません。 |
client_cert_unsupported_key_algorithm
|
検証に使用する PKI に、同じサブジェクトとサブジェクトの公開鍵情報を共有する 11 個以上の中間証明書がある。 検証は実行されません。 |
client_cert_pki_too_large
|
検証に指定された中間証明書に 10 を超える名前の制約がある。 |
|
クライアント証明書に、 |
|
| 証明書チェーンの検証中に制限時間を超過した。 |
client_cert_validation_timed_out
|
証明書チェーンの検証中に、深度または反復処理の上限に達しました。 証明書チェーンの最大深度は、ルート証明書とクライアント証明書を含めて 10 です。反復処理の上限は 100 回です（クライアント証明書チェーンの検証のために確認された証明書）。 |
client_cert_validation_search_limit_exceeded
|
TrustConfig リソースを設定せずに mTLS を構成した。 |
client_cert_validation_not_performed
|
| クライアントが handshake 中にリクエストされた証明書を提示しなかった。 |
client_cert_not_provided
|
クライアント証明書が TrustConfig リソースでの検証に失敗する。 |
client_cert_validation_failed
|
閉じた接続についてログに記録されたエラー
クライアント検証モードが ALLOW_INVALID_OR_MISSING_CLIENT_CERT または REJECT_INVALID に設定されている場合、特定のエラーにより接続が終了し、Cloud Logging にロギングされます。次の表で、これらのエラーについて説明します。
| クライアント証明書のステータス | リクエスト | ロギングされたエラー |
|---|---|---|
| handshake 中にクライアント証明書が署名一致に失敗する。 | SSL handshake を終了します。 | なし |
| サービスで証明書チェーンの検証を実行できない。 | 接続を終端します。 |
client_cert_validation_unavailable
|
| 証明書チェーンの検証中に内部エラーが発生した。 | 接続を終端します。 |
client_cert_validation_internal_error
|
一致する TrustConfig が見つからない。 |
接続を終端します。 |
client_cert_trust_config_not_found
|
| クライアント証明書のペイロード（中間証明書を含む）が大きすぎる（16 KB 超）。 | 接続を終端します。 |
client_cert_exceeded_size_limit
|
バックエンド サービスでロギングが有効になっている場合は、mTLS クライアント証明書の検証中に閉じられた接続についてログに記録されたエラーを表示できます。
制限事項
ロードバランサは、クライアント証明書の失効チェックを行いません。
アプリケーション ロードバランサでは、100 個のトラスト アンカーと 100 個の中間証明書、許可リストに登録済みの 500 個の証明書を含む 1 つのトラストストアを使用して、信頼構成をアップロードできます。すべての中間証明書で、同じサブジェクトとサブジェクトの公開鍵情報を共有する証明書を 3 個以下にする必要があります。詳細については、割り当てと上限をご覧ください。
証明書チェーンの最大深度は、ルート証明書とクライアント証明書を含めて 10 です。信頼チェーンを構築する際に中間証明書を評価できる最大回数は 100 です。詳細については、割り当てと上限をご覧ください。
クライアントからアップロードされ、渡される証明書の鍵は、次のものに制限されます。
- RSA 鍵の長さは 2,048～4,096 ビットです。 詳細については、割り当てと上限をご覧ください。
- ECDSA 鍵では、P-256 または P-384 曲線を使用できます。
クライアントから受信可能な証明書チェーンは、最大 16 KB、10 個の証明書に制限されています。詳細については、割り当てと上限をご覧ください。
検証に使用するルート証明書には、10 個を超える名前の制約を含めることはできません。詳細については、割り当てと上限をご覧ください。