SSL 証明書の概要

SSL/TLS は、インターネットで最も広く使用されている暗号プロトコルです。技術的には TLS は SSL の後継ですが、このドキュメントでは TLS と SSL という用語が同じ意味で使用されています。

Transport Layer Security（TLS）は、ネットワーク経由で情報を送信する際に情報を暗号化し、クライアントとサーバー、またはロードバランサの間でプライバシーを確保するために使用されます。転送ルールでターゲット HTTPS プロキシまたはターゲット SSL プロキシを参照する Google Cloud プロキシ ロードバランサには、ロードバランサのターゲット プロキシ構成の一部として秘密鍵と SSL 証明書が必要になります。

証明書の構成方法

Google Cloud には、HTTP(S) ロードバランサと SSL プロキシ ロードバランサの SSL 証明書を構成する方法が 2 つあります。どちらの方法でも、セルフマネージド SSL 証明書と Google マネージド SSL 証明書がサポートされています。

• Compute Engine SSL 証明書リソース: この方法では、グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、外部プロキシ ネットワーク ロードバランサ、リージョン外部アプリケーション ロードバランサ、内部アプリケーション ロードバランサのターゲット プロキシは、Compute Engine SSL 証明書リソースを参照するように構成されます。SSL 証明書リソースには、秘密鍵とそれに対応する証明書が含まれます。また、必要に応じて CA 証明書も含まれます。この方法は、ロードバランサによってサポートされているすべての Network Service Tiers をサポートしています。

• Certificate Manager: この方法では、グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、または外部プロキシ ネットワーク ロードバランサのターゲット プロキシは、証明書マップを参照するように構成されます。証明書マップには 1 つ以上の証明書エントリが含まれています。各証明書エントリは 1 つの Certificate Manager 証明書リソースを参照します。各証明書リソースには秘密鍵と証明書が含まれます。Certificate Manager を使用すると、ターゲット HTTPS プロキシまたはターゲット SSL プロキシは、数千の SSL 証明書エントリを含む証明書マップを参照できます。この方法は、ロードバランサがプレミアム ネットワーク サービス ティアを使用している場合にのみ使用できます。

  クロスリージョン内部アプリケーション ロードバランサ、リージョン内部アプリケーション ロードバランサ、リージョン外部アプリケーション ロードバランサの場合、Certificate Manager 証明書はターゲット プロキシに関連付けられます。証明書マップはサポートされていません。

  詳細については、以下のドキュメントをご覧ください。

  • Certificate Manager の概要
  • デプロイの概要

次の表に、Google Cloud プロキシ ロードバランサのターゲット HTTPS プロキシまたはターゲット SSL プロキシに接続できる証明書リソースの種類を示します。Compute Engine SSL 証明書はターゲット プロキシに直接接続されますが、Certificate Manager SSL 証明書はターゲット プロキシに直接接続することも、証明書マップ経由で接続することもできます。

証明書のタイプ

• セルフマネージド SSL 証明書は、ユーザー自身で取得して、プロビジョニング、更新する証明書です。セルフマネージド証明書は、次のいずれかの公開鍵証明書タイプになります。

  • ドメイン認証（DV）
  • 組織認証（OV）
  • 拡張認証（EV）証明書

  セルフマネージドの Compute Engine SSL 証明書の詳細については、セルフマネージド SSL 証明書の使用をご覧ください。

  セルフマネージド SSL 証明書と Certificate Manager の詳細については、セルフマネージド証明書をアップロードする（Certificate Manager のドキュメント）またはセルフマネージド証明書をデプロイする（エンドツーエンド チュートリアル）をご覧ください。

• Google マネージド SSL 証明書は、Google Cloud が自動的に取得、管理、更新する証明書です。Google マネージド証明書は、常にドメイン認証（DV）証明書になります。証明書に関連付けられた組織や個人のアイデンティティは証明しません。また、ワイルドカードの共通名はサポートされません。

  Google マネージドの Compute Engine SSL 証明書の詳細については、Google マネージド SSL 証明書の使用をご覧ください。

  Certificate Manager は、ロードバランサの承認、DNS 認証、Certificate Authority Service との統合を使用して、Google マネージド SSL 証明書をサポートします。Google マネージド SSL 証明書と Certificate Manager の詳細については、Certificate Manager のドキュメントでデプロイの概要をご覧ください。

証明書と Google Cloud ロードバランサ

以降のセクションでは、各アプリケーション ロードバランサがさまざまな証明書構成方法をサポートする方法について説明します。

Compute Engine SSL 証明書

次の表に、セルフマネージド Compute Engine SSL 証明書、Google マネージド Compute Engine SSL 証明書、またはその両方をサポートする Google Cloud ロードバランサを示します。

Certificate Manager SSL 証明書

次の表に、Certificate Manager セルフマネージド証明書、Google マネージド証明書、またはその両方をサポートする Google Cloud ロードバランサを示します。

複数の SSL 証明書

複数の証明書をホストする場合は、同じターゲット HTTPS プロキシまたはターゲット SSL プロキシを使用して複数の証明書をホストできます（ロードバランサが複数のドメイン名をサポートしている場合は、これは一般的です）。共通のターゲット プロキシを参照するように 1 つの転送ルール（1 つの IP アドレスとポート）を構成することも、共通のターゲット プロキシを参照する複数の転送ルール（異なる IP アドレスとポート）を構成することもできます。

複数の Compute Engine SSL 証明書リソース

Compute Engine SSL 証明書リソースを使用する場合、各ターゲット プロキシ リソースは、1 つのターゲット HTTPS またはターゲット SSL プロキシで構成可能な SSL 証明書の最大数まで参照できます。詳細については、ロード バランシングの割り当てと上限に関するドキュメントでターゲット プールとターゲット プロキシをご覧ください。

ロードバランサのターゲット プロキシによって参照される最初の Compute Engine SSL 証明書リソースは、ロードバランサのデフォルト（プライマリ）証明書とみなされます。

Certificate Manager を使用した複数の SSL 証明書

ロードバランサで証明書マップとともに Certificate Manager を使用する場合、各ターゲット プロキシ リソースは 1 つの証明書マップを参照します。1 つの証明書マップでは 1 つ以上の証明書エントリを参照できます。ユーザーは、マップのデフォルト（プライマリ）証明書証明書を構成できます。マップ、エントリ、Certificate Manager の証明書の数は、プロジェクトごとに割り当てが可能です。詳細については、Certificate Manager ドキュメントのリソースの割り当てをご覧ください。

Certificate Manager をサポートするロードバランサを使用していて、1 つのターゲット プロキシで多くの SSL 証明書をホストする必要がある場合は、Compute Engine SSL 証明書リソースの代わりに、Certificate Manager を使用します。

証明書の選択方法

クライアントが HTTP(S) または SSL プロキシ ロードバランサに接続すると、クライアントとロードバランサは TLS セッションをネゴシエーションします。TLS セッションのネゴシエーション中に、クライアントはロードバランサがサポートしている TLS 暗号のリスト（ClientHello 内）をロードバランサに送信します。ロードバランサは、クライアントと互換性のある公開鍵アルゴリズムの証明書を選択します。クライアントは、このネゴシエーションで Server Name Indication（SNI）ホスト名をロードバランサに送信することもできます。SNI ホスト名データは、ロードバランサがクライアントに送信する証明書を選択する際に使用されます。

Google Cloud プロキシ ロードバランサは、このセクションで説明する手順に沿って証明書を選択し、クライアントに送信します。次の手順で使用される「デフォルト（プライマリ）SSL 証明書」という用語は、ターゲット プロキシによって参照される最初の Compute Engine SSL 証明書を指します。

1. ロードバランサが証明書の候補を 1 つ選択します。

   • ロードバランサのターゲット プロキシが 1 つの Compute Engine SSL 証明書リソースのみを参照する場合、ロードバランサは構成された唯一の証明書を証明書の候補として使用します。SNI ホスト名の値（指定した場合）はロードバランサに影響しません。ステップ 2 に進みます。

   • ロードバランサのターゲット プロキシが 2 つ以上の Compute Engine SSL 証明書リソースを参照している場合、ロードバランサは次のプロセスを使用して単一の証明書候補を選択します。

     • クライアントが ClientHello で SNI ホスト名を送信しない場合、ロードバランサはデフォルト（プライマリ）SSL 証明書を証明書の候補として使用します。ステップ 2 に進みます。

     • クライアントが送信する SNI ホスト名が証明書の共通名（CN）と一致せず、証明書サブジェクト代替名（SAN）とも一致しない場合、ロードバランサはデフォルト（プライマリ）SSL 証明書を使用します。ステップ 2 に進みます。

     • ロードバランサは、クライアントから送信された SNI ホスト名と一致する証明書の候補を選択します。マッチングは、共通名（CN）証明書とサブジェクト代替名（SAN）の両方の証明書属性に対して最長の接頭辞を使用して行われます。また、RSA 証明書よりも ECDSA 証明書が優先されます。マッチングの方法を説明するために、CN が cats.pets.example.com の証明書と CN が dogs.pets.example.com の証明書を参照するターゲット プロキシについて考えてみましょう。各証明書の SAN には CN 値だけでなく、*.pets.example.com と *.example.com も含まれます。

       • 指定された SNI ホスト名が cats.pets.example.com の場合、ロードバランサは、CN が cats.pets.example.com である証明書を証明書の候補として使用します。ステップ 2 に進みます。
       • 指定された SNI ホスト名が ferrets.pets.example.com の場合、両方の証明書の SAN に *.pets.example.com が含まれているため、ロードバランサはこの 2 つのいずれかを証明書の候補として使用します。この場合、どちらの証明書が候補になるのかを制御できません。ステップ 2 に進みます。

2. 証明書の候補が、クライアントで指定された暗号のいずれかと互換性のある公開鍵アルゴリズムを使用している場合、その候補がクライアントに送信されます。

   • 証明書の公開鍵アルゴリズム（ECDSA または RSA）を含む暗号スイートをクライアントがサポートしていない場合、TLS ネゴシエーションが失敗する可能性があります。
   • ロードバランサは、候補の選択方法の一部として証明書の notValidBefore 属性と notValidAfter 属性を使用しません。たとえば、期限切れの証明書が証明書の候補として選択されている場合、ロードバランサは期限切れの証明書を提供できます。

料金

Google Cloud ロードバランサを使用すると、ネットワーク料金が発生する場合があります。詳しくは、ネットワーキングのすべての料金体系をご覧ください。Certificate Manager の料金については、Certificate Manager のドキュメントの料金をご覧ください。Compute Engine SSL 証明書リソースの使用に追加料金はかかりません。

次のステップ

• Compute Engine SSL 証明書の詳細については、次のページをご覧ください。

  • セルフマネージドの Compute Engine SSL 証明書の詳細については、セルフマネージド SSL 証明書の使用をご覧ください。
  • Google マネージドの Compute Engine SSL 証明書の詳細については、Google マネージド SSL 証明書の使用をご覧ください。
  • Compute Engine SSL 証明書の割り当てと上限（サポートされている鍵の長さを含む）については、ロードバランサのドキュメントで SSL 証明書とターゲット プールとターゲット プロキシをご覧ください。

• Certificate Manager の詳細については、次のページをご覧ください。

  • Certificate Manager の概要。
  • セルフマネージド SSL 証明書と Certificate Manager の詳細については、セルフマネージド証明書をアップロードする（Certificate Manager のドキュメント）またはセルフマネージド証明書をデプロイする（エンドツーエンド チュートリアル）をご覧ください。
  • Google マネージド SSL 証明書と Certificate Manager の詳細については、Certificate Manager ドキュメントの証明書の管理をご覧ください。
  • Certificate Manager の割り当てと上限については、Certificate Manager ドキュメントのリソースの割り当てをご覧ください。

• GKE によって管理されるプロキシ ロードバランサの SSL 証明書を構成する方法の詳細については、HTTP(S) ロード バランシング用 GKE Ingress、GKE Gateway API のドキュメント、スタンドアロン NEG によるコンテナ ネイティブのロード バランシングをご覧ください。

• ロードバランサと転送中の暗号化の詳細については、バックエンドへの暗号化と Google Cloud での転送中の暗号化ホワイトペーパーをご覧ください。