このページでは、Certificate Manager のコア コンポーネントとコンセプトの概要について説明します。
証明書
証明書は、特定のドメイン名またはドメイン ワイルドカードに対して発行される単一の X.509 Transport Layer Security（TLS）（SSL）証明書を表します。
Certificate Manager は、次のタイプの証明書をサポートしています。
- Google マネージド証明書: Google が取得して管理する証明書。 Google Cloud新しい Google マネージド証明書が発行または更新されると、Certificate Manager は証明書に新しく生成された秘密鍵を使用します。
- セルフマネージド 証明書: ご自分で取得、プロビジョニング、更新する証明書です。
Google マネージド証明書
Google マネージド証明書は、 Google Cloud ユーザーに代わって取得して管理する TLS 証明書です。Certificate Manager を使用すると、Google マネージド証明書を作成、管理、自動更新できます。Certificate Manager では、ロードバランサベースの認証または DNS ベースの認証を使用してドメインの所有権を確認することもできます。
Certificate Manager は、公開認証局（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 ベースの認証のみをサポートし、公開 CA から証明書を取得します。
- 相互 TLS のクライアント証明書として Google マネージド証明書を使用することはできません。
公開証明書と秘密証明書
Certificate Manager は、公開証明書と秘密鍵証明書の両方を管理できます。Certificate Manager は、パブリック CA から公開証明書を取得します。公開証明書は、多くの場合、パブリック サービスを保護します。主要なブラウザ、オペレーティング システム、アプリケーションは、Public CA を信頼ルートとして認識します。Certificate Manager は、プライベート サービスでよく使用されるプライベート証明書を CA Service から取得します。
セルフマネージド証明書
ビジネス要件により Google マネージド証明書を使用できない場合は、外部 CA が発行した証明書とそれに関連する鍵をアップロードできます。これらのセルフマネージド証明書の発行と更新は手動で行う必要があります。
ドメインの承認
Certificate Manager を使用すると、次のいずれかの方法で、Google マネージド証明書を発行するドメインの所有権を確認できます。
ロードバランサ認証: DNS レコードを作成せずに、サポートされているロードバランサに証明書を直接デプロイします。
DNS 認証: ドメイン所有権の確認用の専用の DNS レコードを作成した後、証明書をサポートされているロードバランサに直接デプロイします。
詳細については、Google マネージド証明書のドメイン認証のタイプをご覧ください。
セルフマネージド証明書にはドメインの承認は必要ありません。
証明書マップ
証明書マップは、特定の証明書を特定のホスト名に割り当てる 1 つ以上の証明書マップエントリを参照します。証明書マップエントリは、クライアント接続を確立するときにロードバランサが従う選択ロジックも定義します。証明書マップを複数のターゲット プロキシに関連付けて、複数のロードバランサ間で再利用できます。
クライアントが証明書マップで指定されたホスト名をリクエストすると、ロードバランサはそのホスト名にマッピングされた証明書を提供します。それ以外の場合は、ロードバランサはプライマリ証明書を提供します。これは、ターゲット プロキシにリストされている最初の証明書です。詳細については、Certificate Manager の仕組みをご覧ください。
証明書マップの作成と管理の詳細については、証明書マップを管理するをご覧ください。
証明書マップエントリ
証明書マップ エントリは、特定のドメイン名に対して提供される証明書のリストです。同じドメインに異なる証明書セットを定義できます。たとえば、ECDSA 証明書と RSA 証明書をアップロードして、これらを同じドメイン名にマッピングできます。
クライアントがドメイン名に接続すると、ロードバランサは handshake 中にクライアントに提供する証明書の種類をネゴシエートします。
1 つの証明書マップエントリに関連付けることができる証明書は最大で 4 つです。
証明書マップエントリの作成と管理の詳細については、証明書マップエントリを管理するをご覧ください。
信頼構成
信頼構成は、相互 TLS 認証のシナリオで使用する Certificate Manager の公開鍵基盤（PKI）構成を表すリソースです。これは、1 つのトラストストアをカプセル化し、そのトラストストアがトラスト アンカーをカプセル化します。また、必要に応じて 1 つ以上の中間証明書もカプセル化します。
相互 TLS（mTLS）認証の詳細については、Cloud Load Balancing ドキュメントの相互 TLS の概要をご覧ください。
信頼構成とそのコンポーネントの詳細については、信頼構成を管理するをご覧ください。
トラストストア
トラストストアは、相互 TLS 認証シナリオで使用する Certificate Manager の信頼シークレット構成を表します。トラストストアは、1 つのトラスト アンカーと、必要に応じて 1 つ以上の中間証明書をカプセル化します。
信頼構成リソースには、次の制限事項が適用されます。
- 信頼構成リソースには、単一のトラストストアを保持できます。
- トラストストアには、最大 200 個のトラスト アンカーと最大 100 個の中間 CA 証明書を保持できます。
トラスト アンカー
トラスト アンカーは、相互 TLS 認証シナリオで使用する単一のルート証明書を表します。トラスト アンカーはトラストストア内にカプセル化されます。
中間証明書
中間証明書は、ルート証明書またはトラストストア内の別の中間証明書によって署名された証明書です。中間証明書は相互 TLS 認証に使用されます。
中間証明書がある場合は、PKI 構成に応じて、1 つ以上の中間証明書をトラストストア内にカプセル化できます。信頼構成には、既存の中間証明書に加えて、すべての接続リクエストの信頼評価の一部としてすべての中間証明書が含まれます。
許可リストを必要とする証明書
クライアントが自己署名証明書、期限切れの証明書、無効な証明書で認証できるようにするには、信頼構成の allowlistedCertificates フィールドに証明書を追加します。ルート証明書と中間証明書にアクセスできない場合は、証明書を追加することもできます。証明書を許可リストに追加するためにトラストストアは必要ありません。
証明書を許可リストに追加すると、Certificate Manager は、証明書が次の条件を満たしている場合、証明書を有効と見なします。
- 証明書を解析できる。
- クライアントは、証明書の秘密鍵を所有していることを証明します。
- サブジェクト代替名（SAN）フィールドの制約を満たしている。
証明書発行の構成
証明書発行の構成は、Certificate Manager が独自の Certificate Authority Service インスタンスの CA プールを使用して、Google マネージド証明書を発行できるようにするリソースです。証明書発行構成を使用すると、証明書の発行と有効期限のパラメータ、および発行される証明書の鍵アルゴリズムを指定できます。
証明書発行構成の作成と管理の詳細については、証明書発行構成リソースを管理するをご覧ください。