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 証明書はターゲット プロキシに関連付けられます。証明書マップはサポートされていません。

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

証明書のタイプ

独自の証明書を作成することも、Google で証明書を管理することもできます。

  • セルフマネージド 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 ロードバランサを示します。

Compute Engine SSL 証明書のサポート
ロードバランサ セルフマネージド Google マネージド
グローバル外部アプリケーション ロードバランサ*
sslCertificates
sslCertificates
従来のアプリケーション ロードバランサ*
sslCertificates
sslCertificates
リージョン外部アプリケーション ロードバランサ†
regionSslCertificates
リージョン内部アプリケーション ロードバランサ†
regionSslCertificates
クロスリージョン内部アプリケーション ロードバランサ*
外部プロキシ ネットワーク ロードバランサ（SSL プロキシあり）‡
sslCertificates
sslCertificates

* グローバル外部アプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサでは、従来のアプリケーション ロードバランサがスタンダード ティアを使用している場合でも、グローバル ターゲット HTTPS プロキシが使用されます。

† リージョン外部アプリケーション ロードバランサと内部アプリケーション ロードバランサは、リージョン ターゲット HTTPS プロキシを使用します。

‡ 外部プロキシ ネットワーク ロードバランサは、スタンダード ティアであってもグローバル ターゲット SSL プロキシを使用します。

Certificate Manager SSL 証明書

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

ロードバランサ Google マネージド証明書 セルフマネージド証明書
DNS 認証 ロードバランサ認証 Certificate Authority Service（CA Service）
グローバル外部アプリケーション ロードバランサ
info
info
info
info
従来のアプリケーション ロードバランサ
info
info
info
info
グローバル外部プロキシ ネットワーク ロードバランサ
info
info
info
info
クロスリージョン内部アプリケーション ロードバランサ
info
info
info
リージョン外部アプリケーション ロードバランサ
info
info
info
リージョン内部アプリケーション ロードバランサ
info
info
info

複数の 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 プロキシ ロードバランサがクライアントに送信する証明書を選択する際に使用するプロセスは、次のようにモデル化できます。このモデルでは、構成方法に関係なく、ターゲット HTTPS プロキシまたはターゲット SSL プロキシで構成されているすべての SSL 証明書から始めます。

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

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

    • ロードバランサのターゲット プロキシが 2 つ以上の Compute Engine SSL 証明書リソースを参照する場合、または、ロードバランサのターゲット プロキシが 2 つ以上の証明書エントリを持つ Certificate Manager マップを参照する場合、ロードバランサは以下のプロセスで証明書の候補を 1 つ選択します。

      • クライアントが 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 証明書リソースの使用に追加料金はかかりません。

次のステップ

使ってみる

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

無料で開始