困っていること
自己署名証明書での認証が必要である EC2 インスタンスに対して NLB（Network Load Balancer）からバランシング及びヘルスチェックを行いたいと考えています。
そのような構成をとった際に、NLB から EC2 インスタンスへの TCP/HTTPS 通信によるヘルスチェックが正常に行われるかどうかについて教えてください。
どう対応すればいいの?
ヘルスチェックのプロトコルとして TCP を使用する場合、TLS ハンドシェイク以前の TCP 接続確立の成否により正常・異常が判定されれます。そのため自己署名証明書が使用されている場合でも TLS が使用されていることによる影響は受けないためヘルスチェックが行われます。
補足として、NLB とターゲット間のトラフィックにて TLS を使用する場合、ロードバランサーは証明書を検証しない為、自己署名証明書や期限切れの証明書を使用可能です。
ターゲットグループに TLS プロトコルが設定されている場合、ロードバランサーは、ターゲットにインストールした証明書を使用して、ターゲットと TLS 接続を確立します。ロードバランサーはこれらの証明書を検証しません。したがって、自己署名証明書または期限切れの証明書を使用できます。
なおこれは、プロトコルとして HTTPS を用いるヘルスチェックにおいても同様です。TLS 接続が確立され、ターゲットが正常な HTTP レスポンスを返却すれば、ターゲット側で自己署名証明書を利用可能です。
ただし、相互TLS認証（mTLS）を利用している場合、NLB のヘルスチェックではプロトコルとして TCP のみが利用可能であることに留意が必要です。
ターゲットグループが HTTPS ヘルスチェックで構成されている場合、登録されたターゲットが TLS 1.3 のみをサポートしている場合にはそのターゲットはヘルスチェックに失敗します。これらのターゲットは、TLS 1.2 などの以前のバージョンの TLS をサポートしている必要があります。 HTTP または HTTPS ヘルスチェックリクエストの場合、ホストヘッダーには、ターゲットの IP アドレスおよびヘルスチェックポートではなく、ロードバランサーノードの IP アドレスおよびリスナーポートが含まれます。
Network Load Balancer は、TLS 再ネゴシエーションまたは相互 TLS 認証 (mTL) をサポートしていません。mTLS をサポートするには、TLS リスナーの代わりに TCP リスナーを作成します。ロードバランサーはリクエストをそのまま渡すため、ターゲットに mTL を実装できます。
まとめ
前途で案内した参考資料を踏まえ、NLB からのヘルスチェックが正常に行われるためには、以下に留意してください。
-
ヘルスチェックプロトコルの選択
TCP を使用する場合、TLS ハンドシェイク以前の TCP 接続の確立が判定基準となります。HTTPS を使用する場合も同様です。 -
自己署名証明書の利用
NLB は証明書の検証を行わないため、自己署名証明書や期限切れの証明書を使用することが可能です。 -
相互 TLS 認証（mTLS）の場合の制約
NLB のヘルスチェックでは TCP プロトコルのみが利用可能です。
8
