このページでは、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 がドメインの証明書の発行を拒否する場合や、認証局認可（CAA）レコードによって、Public CA がそのドメインの証明書を発行することが明示的に禁止される場合に発生する可能性があります。ドメインの証明書を発行できる CA を制限する方法については、Google マネージド証明書を発行できる CA を指定するをご覧ください。
Certificate Manager で Google マネージド証明書を使用する際は、次の点にご留意ください。
- Certificate Manager は、RSA Google マネージド証明書をサポートしています。
- リージョン Google マネージド証明書は、DNS ベースの認証のみをサポートし、パブリック CA から証明書を取得します。
- 相互 TLS のクライアント証明書として Google マネージド証明書を使用することはできません。
有効期間が 30 日の
EDGE_CACHEを除くすべてのスコープで、Google が管理するパブリック証明書のデフォルトの有効期間は、発行元の CA に応じて 45 日または 90 日です。- Public CA によって発行された証明書は、有効期間が 90 日から 45 日に段階的に移行しています。既存の 90 日間の証明書は、次の更新まで 90 日間有効です。
- Let's Encrypt CA が発行した証明書の有効期間は 90 日間です。
公的に信頼されている Google マネージド証明書のデフォルトの有効期間は変更できません。
パブリック証明書とプライベート証明書
Certificate Manager は、一般公開証明書と限定公開証明書の両方を管理できます。Certificate Manager は、Public CA から公開証明書を取得します。公開証明書は、多くの場合、公開サービスを保護します。主要なブラウザ、オペレーティング システム、アプリケーションは、Public CA をルート オブ トラストとして認識します。Certificate Manager は、プライベート サービスを保護するプライベート証明書を CA Service から取得します。
セルフマネージド証明書
ビジネス要件により Google マネージド証明書を使用できない場合は、外部 CA が発行した証明書とそれに関連する鍵をアップロードできます。これらのセルフマネージド証明書は、手動で発行および更新する必要があります。
セルフマネージド証明書の Certificate リソースには、証明書とそのチェーンを含める必要があります。証明書チェーンには、ルート証明書への信頼を確立するのに役立つ中間証明書が含まれています。証明書チェーンは、単一の PEM エンコード ファイルまたはテキスト ブロックとして追加できます。
証明書チェーンは次の順序で指定してください。
- リーフ証明書
- すべての中間証明書
サポートされている鍵の種類
ロードバランサは、さまざまな鍵の種類の秘密鍵を使用する証明書をサポートしています。次の表に、証明書がセルフマネージドか 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 マネージド証明書を発行できるようにするリソースです。証明書発行の構成では、証明書の発行と有効期限のパラメータ、発行された証明書の鍵アルゴリズムを指定できます。
証明書発行構成の作成と管理の詳細については、証明書発行構成リソースを管理するをご覧ください。