SSL 証明書の概要
コレクションでコンテンツを整理必要に応じて、コンテンツの保存と分類を行います。

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

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

証明書の構成方法

Google Cloud には、ターゲット HTTPS プロキシを使用するアプリケーションロードバランサと、ターゲット SSL プロキシを使用するプロキシネットワークロードバランサの証明書構成方法が 3 つあります。

ターゲットプロキシによる Compute Engine SSL 証明書の参照: この方法では、ロードバランサのターゲットプロキシは最大 15 個の Compute Engine SSL 証明書リソースを参照できます。各 Compute Engine SSL 証明書リソースには、秘密鍵、対応する証明書、必要に応じて CA 証明書が含まれます。
ターゲットプロキシによる Certificate Manager 証明書マップの参照: この方法では、ロードバランサのターゲットプロキシは 1 つの証明書マップを参照します。証明書マップはデフォルトで数千のエントリをサポートし、数百万のエントリにスケーリングできます。各エントリには、秘密鍵と証明書データが含まれています。
ターゲットプロキシによる Certificate Manager 証明書の直接参照: この方法では、ロードバランサのターゲットプロキシは最大 100 個の Certificate Manager 証明書を参照できます。

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

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

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

構成方法のルール

Google Cloud は、次の証明書構成方法のルールを適用します。

Compute Engine SSL 証明書と Certificate Manager 証明書マップの両方をサポートするロードバランサの場合: ロードバランサのターゲットプロキシは、証明書マップと 1 つ以上の Compute Engine SSL 証明書の両方を同時に参照できます。ただし、この場合、Compute Engine SSL 証明書はすべて無視され、ロードバランサは証明書マップの証明書のみを使用します。
Compute Engine SSL 証明書と直接接続された Certificate Manager 証明書の両方をサポートするロードバランサの場合: ロードバランサのターゲットプロキシは、最大 15 個の Compute Engine SSL 証明書または最大 100 個の Certificate Manager 証明書を参照するようにのみ構成できます。両方の組み合わせはできません。

証明書のタイプ

Google Cloud は、セルフマネージド証明書と Google マネージド証明書の両方をサポートしています。

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

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

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

セルフマネージド SSL 証明書は、次の方法で作成できます。

Compute Engine SSL 証明書リソース: 詳細については、セルフマネージド SSL 証明書を使用するをご覧ください。
Certificate Manager: 詳細については、Certificate Manager ドキュメントのデプロイの概要をご覧ください。

Google マネージド SSL 証明書

Google マネージド SSL 証明書は、 Google Cloudが自動的に取得、管理、更新する証明書です。Google マネージド証明書は、常にドメイン認証（DV）証明書になります。証明書に関連付けられた組織や個人の ID は証明しません。

ワイルドカードを使用する Google マネージド証明書は、DNS 認証を使用している場合にのみ Certificate Manager でサポートされます。

Google マネージド SSL 証明書は、次の方法で作成できます。

Compute Engine SSL 証明書リソース: Google マネージド SSL 証明書をサポートするのは、グローバル Compute Engine sslCertificates リソースのみです。regionSslCertificates はサポートしていません。詳細については、Google マネージド SSL 証明書を使用するをご覧ください。
Certificate Manager: 詳細については、Certificate Manager ドキュメントのデプロイの概要をご覧ください。

複数の SSL 証明書

アプリケーションロードバランサまたはプロキシネットワークロードバランサは、ターゲットプロキシがサポートされている証明書構成方法を使用して構成されている場合、2 つ以上の SSL 証明書を同時にホストできます。ベストプラクティスとして、複数の SSL 証明書が必要な場合は Certificate Manager を使用します。

Compute Engine SSL 証明書をサポートするロードバランサの場合: ロードバランサのターゲットプロキシは、最大 15 個の Compute Engine SSL 証明書を参照できます。最初に参照される Compute Engine SSL 証明書リソースは、ターゲットプロキシのデフォルト（プライマリ）証明書です。
Certificate Manager 証明書マップをサポートするロードバランサの場合: ロードバランサのターゲットプロキシは、単一の証明書マップを参照します。証明書マップは、数千の証明書マップエントリをサポートしています。証明書マップのデフォルト（プライマリ）証明書を構成できます。
Certificate Manager 証明書の直接参照をサポートするロードバランサの場合: ロードバランサのターゲットプロキシは、最大 100 個の Certificate Manager 証明書を参照できます。最初に参照される Certificate Manager SSL 証明書リソースは、ターゲットプロキシのデフォルト（プライマリ）証明書です。

詳しくは以下をご覧ください。

ロードバランシングのドキュメントのターゲットプロキシとSSL 証明書。
Certificate Manager ドキュメントのリソースの割り当てと上限。

証明書の選択プロセス

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

ロードバランサのターゲットプロキシが Certificate Manager 証明書マップを参照する場合、証明書の選択プロセスは異なります。証明書マップの証明書選択プロセスの詳細については、Certificate Manager のドキュメントの証明書選択のロジックをご覧ください。

クライアントがロードバランサに接続すると、クライアントとロードバランサは 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 ネゴシエーションは失敗します。

料金

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

次のステップ

Certificate Manager の概要

バックエンドへの暗号化
ホワイトペーパー: Google Cloudでの転送データの暗号化

使ってみる

Google Cloudを初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

無料で開始