Certificate Manager のコア コンポーネント

このページでは、Certificate Manager のコア コンポーネントとコンセプトの概要について説明します。

証明書

証明書は、特定のドメイン名またはドメイン ワイルドカードに対して発行される単一の X.509 Transport Layer Security(TLS)(SSL)証明書を表します。

Certificate Manager は、次のタイプの証明書をサポートしています。

  • Google マネージド証明書: Google Cloud が取得して管理する証明書。新しい Google マネージド証明書が発行または更新されると、Certificate Manager は証明書用に新たに生成された秘密鍵を使用します。
  • セルフマネージド証明書: ご自分で取得、プロビジョニング、 更新する証明書。

Google マネージド証明書

Google マネージド証明書は、 Google Cloud が取得 して管理する TLS 証明書です。Certificate Manager を使用すると、Google マネージド証明書を作成、管理、自動更新できます。 また、Certificate Manager では、ロードバランサベースの承認または DNS ベースの承認を使用して、ドメインの所有権を確認できます。

Certificate Manager は、Public Certificate Authority(CA)と Let's Encrypt CA をサポートしています。デフォルトでは、Public CA が Google マネージド証明書を発行します。特定のドメインの Public CA から証明書を取得できない場合、Certificate Manager は Let's Encrypt CA にフォールバックします。これは、Public CA がドメインの証明書の発行を拒否する場合や、Certificate Authority Authorization(CAA)レコードによって、Public CA がそのドメインの証明書を発行することが明示的に禁止される場合に発生する可能性があります。ドメインの証明書を発行する可能性のある CA を制限する方法については、Google マネージド証明書を発行できる CA を指定するをご覧ください。

Certificate Manager で Google マネージド証明書を使用する場合は、次の点に注意してください。

  • Certificate Manager は、RSA Google マネージド証明書をサポートしています。
  • リージョン Google マネージド証明書は、DNS ベースの承認のみをサポートし、Public CA から証明書を取得します。
  • 相互 TLS のクライアント証明書として Google マネージド証明書を使用することはサポートされていません。
  • パブリック Google マネージド証明書のデフォルトの有効期間は、 EDGE_CACHE を除くすべてのスコープで 90 日間です。 の有効期間は 30 日間です。パブリック Google マネージド証明書の有効期間を変更することはできません。

パブリック証明書とプライベート証明書

Certificate Manager は、パブリック証明書とプライベート証明書の両方を管理できます。Certificate Manager は、公開サービスを保護することが多いパブリック証明書を Public CA から取得します。主要なブラウザ、オペレーティング システム、アプリケーションは、Public CA をルート オブ トラストとして認識します。Certificate Manager は、プライベート サービスを保護することが多いプライベート証明書を CA Service から取得します。

セルフマネージド証明書

ビジネス要件により Google マネージド証明書を使用できない場合は、外部 CA が発行した証明書とそれに関連する鍵をアップロードできます。これらのセルフマネージド証明書は、手動で発行して更新する必要があります。

セルフマネージド証明書の Certificate リソースには、証明書とそのチェーンを含める必要があります。証明書チェーンには、ルート証明書への信頼を確立するのに役立つ 中間証明書が含まれています。証明書チェーンは、単一の PEM エンコード ファイルまたはテキスト ブロックとして追加できます。

証明書チェーンは次の順序で指定してください。

  1. リーフ証明書
  2. すべての中間証明書

サポートされている鍵の種類

ロードバランサは、さまざまな鍵の種類の秘密鍵を使用する証明書をサポートしています。次の表に、証明書がセルフマネージドか Google マネージドかによって、サポートされる鍵の種類を示します。
SSL 証明書の種類 arrow_forward

鍵の種類 arrow_downward
Certificate Manager SSL 証明書
グローバルとリージョナル
セルフマネージド 公的に信頼されている Google マネージド 組織内で信頼する Google マネージド
RSA-2048
RSA-3072
RSA-4096
ECDSA P-256
ECDSA P-384

ドメインの承認

Certificate Manager を使用すると、次のいずれかの方法で、Google マネージド証明書を発行するドメインの所有権を確認できます。

  • ロードバランサの承認: DNS レコードを作成せずに、 サポートされているロードバランサに証明書を直接デプロイします。

  • DNS 承認: ドメインの所有権を確認するための専用の DNS レコードを作成した後、サポートされているロード バランサに証明書を直接デプロイします。

詳細については、Google マネージド証明書のドメイン認証のタイプ をご覧ください

セルフマネージド証明書にはドメインの承認は必要ありません。

証明書マップ

証明書マップは、特定の証明書を特定のホスト名に割り当てる 1 つ以上の証明書マップエントリを参照します。証明書マップエントリは、クライアント接続を確立するときにロードバランサが従う選択ロジックも定義します。証明書マップを複数のターゲット プロキシに関連付けて、複数のロードバランサ間で再利用できます。

クライアントが証明書マップで指定されたホスト名をリクエストすると、ロードバランサはそのホスト名にマッピングされた証明書を提供します。それ以外の場合は、ロードバランサはプライマリ証明書を提供します。これは、ターゲット プロキシにリストされている最初の証明書です。詳細については、Certificate Manager の仕組みをご覧ください。

次のロードバランサは証明書マップをサポートしています。

  • グローバル外部アプリケーション ロードバランサ
  • グローバル外部プロキシ ネットワーク ロードバランサ

証明書マップの作成と管理の詳細については、証明書マップを管理する をご覧ください。

証明書マップエントリ

証明書マップ エントリは、特定のドメイン名に対して提供される証明書のリストです。同じドメインに対して異なる証明書セットを定義できます。 たとえば、ECDSA 証明書と RSA 証明書をアップロードして、これらを同じドメイン名にマッピングできます。

クライアントがドメイン名に接続すると、ロードバランサは handshake 中にクライアントに提供する証明書の種類をネゴシエートします。

1 つの証明書マップエントリに関連付けることができる証明書は最大で 4 つです。

証明書マップエントリの作成と管理の詳細については、 証明書マップエントリを管理するをご覧ください。

信頼構成

信頼構成は、Certificate Manager の公開鍵基盤(PKI)構成を表すリソースです。信頼構成は、相互 TLS(mTLS)認証と TLS インスペクションのシナリオで使用できます。信頼構成は、1 つのトラストストアをカプセル化します。このトラストストアは、1 つ以上のトラスト アンカーと、必要に応じて 1 つ以上の中間証明書をカプセル化します。

アプリケーション ロードバランサの次の相互 TLS シナリオで信頼構成を使用できます。

  • フロントエンド mTLS: クライアント とロードバランサ間の接続を認証します。ロードバランサは、信頼構成を使用してクライアントの ID を検証します。詳細については、相互 TLS の概要をご覧ください。
  • バックエンド mTLS: ロードバランサ とバックエンド ワークロード(仮想マシン(VM)インスタンスなど)間の接続を認証します。このシナリオでは、ロードバランサは信頼構成を使用して、バックエンドから提示された証明書を検証します。詳細については、バックエンド 認証済み TLS とバックエンド mTLS の概要をご覧ください。

また、Cloud Next Generation Firewall(Cloud NGFW)では、次のユースケースで信頼構成を使用できます。

  • TLS インスペクション: プライベート署名されたバックエンド証明書を検証します。 信頼構成と認証局(CA)プールの構成を TLS インスペクション ポリシーに追加し、ファイアウォール エンドポイントに接続してトラフィックを復号して検査できます。詳細については、 TLS インスペクションの概要TLS インスペクションを設定するをご覧ください。

信頼構成とそのコンポーネントの詳細については、信頼構成 を管理するをご覧ください。

トラストストア

トラストストアは、相互 TLS 認証シナリオで使用する Certificate Manager の信頼シークレット構成を表します。トラストストアは、1 つのトラスト アンカーと、必要に応じて 1 つ以上の中間証明書をカプセル化します。

信頼構成リソースには、次の制限事項が適用されます。

  • 信頼構成リソースは、1 つのトラストストアを保持できます。
  • トラストストアには、最大 100 個の中間 CA 証明書を保持できます。許可リスト内のトラスト アンカー、 中間証明書、証明書の合計サイズは、 プロジェクトの 信頼構成サイズの 計算に則って管理されます。

トラスト アンカー

トラスト アンカーは、相互 TLS 認証シナリオで使用する単一のルート証明書を表します。トラスト アンカーはトラストストア内にカプセル化されます。

中間証明書

中間証明書は、ルート証明書またはトラストストア内の中間証明書によって署名された証明書です。中間証明書は、相互 TLS 認証に使用されます。

中間証明書がある場合は、PKI 構成に応じて、1 つ以上の中間証明書をトラストストア内にカプセル化できます。 既存の中間証明書に加えて、信頼構成には、すべての接続リクエストの信頼評価の一部としてすべての中間証明書が含まれます。

許可リストを必要とする証明書

自己署名証明書、期限切れの証明書、無効な証明書でクライアントを認証できるようにするには、証明書を信頼構成の allowlistedCertificates フィールドに追加します。ルート証明書と中間証明書にアクセスできない場合でも、証明書を追加できます。 証明書を許可リストに追加するためにトラストストアは必要ありません。

証明書を許可リストに追加すると、証明書が次の条件を満たしている場合、Certificate Manager は証明書を有効とみなします。

  • 証明書を解析できる。
  • クライアントが証明書の秘密鍵を所有していることを証明する。
  • サブジェクト代替名(SAN)フィールドの制約が満たされている。

証明書発行の構成

証明書発行の構成は、Certificate Manager が独自の Certificate Authority Service インスタンスの CA プールを使用して、Google マネージド証明書を発行できるようにするリソースです。証明書発行の構成では、証明書の発行と有効期限のパラメータ、発行された証明書の鍵アルゴリズムを指定できます。

証明書発行の構成の作成と管理の詳細については、 証明書発行の構成リソース を管理するをご覧ください。

次のステップ