SSL 証明書の概要

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

Transport Layer Security（TLS）は、ネットワーク経由で情報を送信する際に情報を暗号化し、クライアントとサーバー、またはロードバランサの間でプライバシーを確保するために使用されます。SSL を使用するアプリケーション ロードバランサまたはプロキシ ネットワーク ロードバランサには、少なくとも 1 つの秘密鍵と SSL 証明書が必要です。

証明書の構成方法

ターゲット HTTPS プロキシを使用するアプリケーション ロードバランサの場合、ロードバランサのターゲット プロキシは 1～15 個の Compute Engine SSL 証明書を参照する必要があります。各 Compute Engine SSL 証明書リソースには、秘密鍵、対応する証明書、必要に応じて CA 証明書が含まれます。

ロードバランサのサポート

次の表は、各ロードバランサがサポートする証明書構成方法を示しています。

ロードバランサ 証明書の構成方法: ターゲット プロキシが参照するもの
Compute Engine SSL 証明書 Certificate Manager 証明書マップ Certificate Manager 証明書を直接使用
アプリケーション ロードバランサ（ターゲット HTTPS プロキシ）
リージョン外部アプリケーション ロードバランサ リージョン証明書をサポート
セルフマネージド
Google マネージド 		セルフマネージド
Google マネージド
リージョン内部アプリケーション ロードバランサ リージョン証明書をサポート
セルフマネージド
Google マネージド 		セルフマネージド
Google マネージド

証明書のタイプ

ロードバランサにセルフマネージド SSL 証明書を作成できます。

セルフマネージド SSL 証明書

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

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

セルフマネージド SSL 証明書は、Compute Engine SSL 証明書リソースを使用して作成できます。詳細については、セルフマネージド SSL 証明書を使用するをご覧ください。

複数の SSL 証明書

アプリケーション ロードバランサのターゲット プロキシは、最大 15 個の Compute Engine SSL 証明書を参照できます。最初に参照される Compute Engine SSL 証明書リソースは、ターゲット プロキシのデフォルト（プライマリ）証明書です。

詳細については、ロード バランシングのドキュメントのターゲット プロキシとSSL 証明書をご覧ください。

証明書の選択プロセス

次の証明書選択プロセスは、ターゲット プロキシが複数の Compute Engine SSL 証明書を参照するロードバランサに適用されます。

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

  • ロードバランサのターゲット プロキシが 1 つの証明書のみを参照している場合、その証明書が使用され、クライアントから送信された SNI ホスト名の値は無関係です。

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

    • クライアントが ClientHello で SNI ホスト名を送信しなかった場合、ロードバランサは証明書リストの最初の証明書を使用します。

    • クライアントが送信する SNI ホスト名が証明書の共通名（CN）と一致せず、証明書サブジェクト代替名（SAN）とも一致しない場合、ロードバランサは証明書リスト内の最初の証明書を使用します。

    • その他の状況: ロードバランサは、次のマッチング プロセスを使用して証明書を選択します。

      • マッチングは、共通名（CN）証明書とサブジェクト代替名（SAN）の両方の証明書属性に対して最長の接尾辞を使用して行われます。また、RSA 証明書よりも ECDSA 証明書が優先されます。

      • マッチングの方法を説明するために、次の 2 つの証明書を参照するターゲット プロキシについて考えてみましょう。

        • 証明書 A

          • CN: cats.pets.example.com
          • SAN: cats.pets.example.com、*.pets.example.com、*.example.com

        • 証明書 B

          • CN: dogs.pets.example.com
          • SAN: dogs.pets.example.com、*.pets.example.com、*.example.com

      • 次のシナリオについて考えてみましょう。

        • クライアントから送信された SNI ホスト名が cats.pets.example.com の場合、ロードバランサは証明書 A を使用します。
        • クライアントから送信された SNI ホスト名が ferrets.pets.example.com の場合、完全に一致しないため、ロードバランサは証明書 A または証明書 B のいずれかを選択します。どちらも SAN リストに *.pets.example.com が含まれているためです。この場合、どちらの証明書が選択されるかを制御することはできません。

  • 証明書が選択されると、ロードバランサは、選択した証明書が ClientHello でクライアントから送信された暗号と互換性のある公開鍵アルゴリズムを使用している場合のみ、その証明書をクライアントに送信します。ロードバランサが選択した証明書の公開鍵アルゴリズム（ECDSA または RSA）を含む暗号スイートをクライアントがサポートしていない場合、TLS ネゴシエーションは失敗します。

次のステップ