Certificate Manager の柔軟なマッピング メカニズムを使用すると、割り当て先の証明書と、環境内のドメイン名ごとに証明書の提供方法をきめ細かく制御できます。このメカニズムには次のエンティティが含まれています。
- 証明書
- 証明書マップ
- 証明書マップエントリ
- ドメインの承認
次の図は、ロードバランサの転送ルールで指定された一般的なターゲット プロキシのこれらのエンティティ間の関係を示しています。
Certificate Manager は、ターゲット HTTPS プロキシとターゲット SSL プロキシをサポートしています。これらのプロキシタイプの違いについて詳しくは、ターゲット プロキシの使用をご覧ください。
Certificate Manager がサポートする証明書のタイプについては、デプロイの概要をご覧ください。
証明書
デフォルトでは、証明書は特定のドメイン名またはドメイン ワイルドカードに対して発行される単一の X.509 Transport Layer Security（TLS）証明書を表します。
Certificate Manager は次の種類の証明書をサポートしています。
- Google マネージド証明書は、Google Cloud が取得して管理する証明書です。
- セルフマネージド SSL 証明書は、ご自分で取得、プロビジョニング、更新する証明書です。
公的に信頼できる CA を使用して証明書を発行すると、CA は関連するドメインに関する情報を Certificate Transparency ログ（公開アクセス可能）に公開します。これは、すべての公的に信頼できる CA が採用している標準の証明書発行プロセスの一部であり、Google マネージド証明書とセルフマネージド証明書の両方に適用されます。ただし、Certificate Authority Service を使用して Google マネージド証明書を発行する場合、Certificate Manager は Certificate Transparency ログに情報を公開しません。
詳しくは、Certificate Transparency（証明書の透明性）をご覧ください。
Certificate Manager を使用して証明書をデプロイする方法については、デプロイの概要をご覧ください。
Google マネージド証明書
ウェブサイトやアプリケーションでの Google マネージド TLS（SSL）証明書の管理は、多くの場合、手動構成と定期的なメンテナンスを必要とする複雑で時間のかかる作業になります。Certificate Manager は、一元化されたプラットフォームを提供することでこのプロセスを合理化するためのサービスです。証明書を発行および更新する作業を Certificate Manager に委任できるため、お客様は他の重要なタスクに専念できます。
ロードバランサベースまたは DNS ベースの承認を使用して、関連するドメイン所有権を確認できます。Certificate Manager は、RSA Google マネージド証明書をサポートしています。
デフォルトでは、Google CA が Google マネージド証明書を発行します。新しい Google マネージド証明書が発行または更新されると、新たに生成された秘密鍵が使用されます。特定のドメインの Google CA から証明書を取得できない場合、Certificate Manager は Let's Encrypt CA にフォールバックします。たとえば、Google CA がドメインの証明書の発行を拒否する場合や、CA 認可レコードによって、Google CA がそのドメインの証明書を発行することが明示的に禁止される場合があります。
クライアント側のみの認証はサポートされていません。
ドメインの証明書を発行できる CA を制限する方法については、Google マネージド証明書を発行できる CA の指定をご覧ください。
リージョン Google マネージド証明書（プレビュー）は、DNS ベースの承認のみをサポートし、Google CA から取得します。
Certificate Authority Service によって発行された Google マネージド証明書
証明書を発行するために Google が承認した Public CA に依存するのではなく、独自の信頼チェーンを使用する場合は、代わりに認証局として Certificate Authority Service から CA プールを使用するように Certificate Manager を構成できます。CA プールの詳細については、CA プールの作成をご覧ください。
セルフマネージド証明書
ビジネス要件によって Google マネージド証明書の使用が禁止されている場合は、外部 CA が発行した証明書とそれに関連する鍵をアップロードできます。セルフマネージド証明書を手動で発行および更新する作業は、お客様自身で行う必要があります。
Certificate Manager では、安全なウェブプロキシ プロキシとリージョン ロードバランサにリージョンのセルフマネージド証明書をデプロイすることもできます。
証明書マップ
証明書マップは、特定の証明書を特定のホスト名に割り当てる 1 つ以上の証明書マップエントリを参照します。証明書マップエントリは、クライアント接続を確立するときにロードバランサが従う選択ロジックも定義します。証明書マップを複数のターゲット プロキシに関連付けることで、複数のロードバランサで再利用できます。
クライアントが証明書マップで指定されたホスト名をリクエストすると、ロードバランサはそのホスト名にマッピングされた証明書を提供します。それ以外の場合、ロードバランサはプライマリ証明書を提供します。詳細については、証明書の選択ロジックをご覧ください。
証明書マップエントリ
証明書マップエントリは、特定のドメイン名に対して提供される証明書のリストです。ドメインやサブドメインなど、異なるドメイン名に異なる証明書セットを定義できます。たとえば、ECDSA 証明書と RSA 証明書をアップロードして、同じドメイン名にマッピングできます。クライアントがそのドメイン名に接続すると、ロードバランサが handshake 中にクライアントに提供する証明書のタイプをネゴシエートします。
ドメインの承認
Certificate Manager を使用すると、次の表に示すように、Google マネージド証明書を発行するドメインの所有権を確認できます。
| ロードバランサの承認 | DNS 認証 | |
|---|---|---|
| 設定の難易度 | 追加の構成手順や DNS 構成の変更は必要ありません。 | DNS 認証を作成し、対応する CNAME レコードを DNS 構成に追加する必要があります。 |
| ネットワーク セキュリティ | ロードバランサは、証明書によって提供されるすべてのドメインの DNS 構成を含め、インターネットからポート 443 で完全にアクセス可能である必要があります。他の構成では機能しません。 | ターゲット プロキシの前にある 443 以外のポートや CDN レイヤなど、非常に複雑な構成で動作します。 |
| プロビジョニングの速度 | 証明書をプロビジョニングできるのは、ロードバランサが完全に設定され、ネットワーク トラフィックを処理している場合のみです。 | ターゲット プロキシがネットワーク トラフィックを処理する準備が整う前に、事前に証明書をプロビジョニングできます。 |
各メソッドを使用して Certificate Manager がドメインの所有権を確認する方法については、Google マネージド証明書に対するドメインの承認をご覧ください。
証明書発行の構成
証明書発行の構成は、Certificate Manager が独自の Certificate Authority Service インスタンスの CA プールを使用して、Google CA や Let's CA を暗号化します。このポリシーでは、証明書の発行と有効期限を制御するさまざまなパラメータを指定できます。また、この方法で発行される証明書の鍵アルゴリズムも選択できます。
信頼構成
信頼構成は、相互 TLS 認証のシナリオで使用する Certificate Manager の公開鍵基盤（PKI）構成を表すリソースです。これは、1 つのトラストストアをカプセル化し、そのトラストストアがトラスト アンカーをカプセル化します。また、必要に応じて 1 つ以上の中間証明書もカプセル化します。
相互 TLS 認証の詳細については、Cloud Load Balancing ドキュメントの相互 TLS 認証をご覧ください。
信頼構成リソースは、トラストストア、トラスト アンカー、中間証明書のエンティティをカプセル化します。
トラストストア
トラストストアは、相互 TLS 認証シナリオで使用する Certificate Manager の信頼シークレット構成を表します。単一のトラスト アンカーと、必要に応じて 1 つ以上の中間証明書をカプセル化します。
トラスト アンカー
トラスト アンカーは、相互 TLS 認証シナリオで使用する単一のルート証明書を表します。トラストストア内にカプセル化されます。
中間証明書
中間証明書は、ルート TLS によって署名された単一の中間証明書、または相互 TLS 認証シナリオで使用するカプセル化されたトラストストアで参照される中間証明書を表します。
PKI 構成に応じて、1 つ以上の中間証明書をトラストストア内にカプセル化できます。信頼構成内で指定されたすべての中間証明書は、リクエスト自体で指定された中間証明書のリストに加えて、すべての接続リクエストの信頼評価の一部として含まれます。
許可リストに登録済みの証明書
許可リストに登録済みの証明書は、信頼構成内でカプセル化できる任意の証明書を表し、常に有効と見なされます。許可リストに登録済みの証明書は、証明書が解析可能で、秘密鍵の所有の証明が確立され、証明書の SAN フィールドの制約が満たされている限り、常に有効とみなされます。期限切れの証明書も、許可リストに登録されている場合は有効とみなされます。許可リストに登録済みの証明書を使用する場合、トラストストアは必要ありません。
証明書の選択ロジック
大まかに言えば、ロードバランサは次のように証明書を選択します。
- クライアントが handshake を開始します。この手順では、handshake を実行するために使用できる暗号アルゴリズムのリストをロードバランサに提供します。必要に応じてホスト名を指定することもできます。
ロードバランサは、クライアントが提供するホスト名と構成済みの証明書マップのエントリに基づいて、セキュアな handshake を実行するための証明書を選択します。ロードバランサが選択する証明書は、次の要因によって決まります。
ホスト名が完全に一致する: クライアントがプロビジョニングされた証明書マップのエントリと完全に一致するホスト名を提供した場合、ロードバランサは対応する証明書を選択します。
ワイルドカードを含むホスト名が一致する: クライアントのホスト名がエントリとは一致しないが、証明書マップ エントリのワイルドカードを含むホスト名とは一致する場合、ロードバランサはこのエントリ内の対応する証明書を選択します。たとえば、
*.myorg.example.comとして構成されるワイルドカード エントリは、myorg.example.comドメインの第 1 レベルのサブドメインを対象とします。ホスト名は一致しないが、事前構成されたプライマリ証明書マップのエントリが一致する: ロードバランサは、ホスト名またはプロビジョニングされた証明書エントリの一致が見つからない場合、事前構成されたプライマリ証明書マップのエントリを選択します。
handshake が失敗する: 次の理由でロードバランサが一致する証明書を見つけられない場合、handshake は失敗します。
- クライアントが、プロビジョニングされたすべての証明書マップエントリで指定されたホスト名と完全一致しない、またはワイルドカードを含むホスト名と一致しないホスト名を提供しているか、ホスト名をまったく提供していない。
- 一致するプライマリ証明書マップのエントリが見つからないか、プライマリ証明書マップのエントリが構成されていない。
証明書の優先度
ロードバランサは、以下に基づいて証明書マップエントリ内の証明書を選択します。
- 証明書の種類。接続しているクライアントがより安全な ECDSA 証明書をサポートしている場合、ロードバランサはこれらの証明書を RSA 証明書より優先します。クライアントが ECDSA 証明書のサポートを指定していない場合、ロードバランサは RSA 証明書を処理します。
- 証明書のサイズ。ロードバランサでは、サイズが小さい証明書から大きい証明書への順に優先されます。
ワイルドカード ドメイン名
ワイルドカード ドメイン名には次のルールが適用されます。
- ワイルドカード ドメイン名をサポートするのは、DNS 認証を含む Google マネージド証明書と CA サービスを使用した Google マネージド証明書のみです。ロードバランサの承認を使用した Google マネージド証明書は、ワイルドカード ドメイン名をサポートしていません。
- 両方がエントリで定義されている場合、完全一致がワイルドカードよりも優先されます。たとえば、
www.myorg.example.comと*.myorg.example.comに対して証明書マップ エントリを構成した場合、www.myorg.example.comに対する接続リクエストでは、*.myorg.example.comも存在している場合でも、常にwww.myorg.example.comに対するエントリが選択されます。 - ワイルドカード ドメイン名は、1 つのサブドメイン レベルまでしか一致しません。たとえば、
host1.myorg.example.comに対する接続リクエストでは、*.myorg.example.comに対する証明書マップエントリが選択されますが、host1.hosts.myorg.example.comに対する証明書マップエントリは選択されません。
Public CA
Certificate Manager の Public CA 機能を使用するには、次のコンセプトについて理解している必要があります。
ACME クライアント。自動証明書管理環境（ACME）クライアントは、ACME プロトコルを使用する証明書管理クライアントです。Public CA と連携するには、ACME クライアントが外部アカウント バインディング（EAB）をサポートしている必要があります。
外部アカウント バインディング（EAB）。Certificate Manager Public CA で使用する各 ACME アカウントは、外部アカウント バインディングを使用して、対象の Google Cloud プロジェクトにバインドする必要があります。そのためには、対応する Google Cloud プロジェクトにリンクされている Secret を使用して、各 ACME アカウントを登録する必要があります。詳細については、外部アカウント バインディングをご覧ください。
Public CA のチャレンジ
Public CA を使用して証明書をリクエストすると、Certificate Manager は、証明書に一覧表示されているドメインを制御することを証明するよう求められます。チャレンジを解決することでドメイン管理を証明できます。Public CA は、ターゲット ドメインの制御を証明した後にドメイン名を承認します。
必要な承認を取得すると、特定の期間だけ有効な証明書をリクエストできます。この期限を経過したら、3 種類のチャレンジのいずれかを解決して証明書を再度リクエストし、ドメイン名を再検証する必要があります。
本人確認の種類
Public CA は、次の種類のチャレンジをサポートします。
HTTP チャレンジ。このチャレンジには、Public CA がファイルを取得して確認できるように、HTTP サーバー（ポート 80）上の既知の場所にファイルを作成することが含まれます。詳細については、HTTP チャレンジをご覧ください。
TLS アプリケーション レイヤ プロトコル ネゴシエーション（ALPN）チャレンジ。ドメインを制御するために、ポート 443 での TLS ネゴシエーション中に特定の証明書を提供するようサーバーに要求します。詳細については、ACME TLS-ALPN チャレンジの拡張機能をご覧ください。
DNS チャレンジ。ドメインに対する制御を証明するために、定義された場所に特定の DNS レコードを追加する必要があります。詳細については、DNS チャレンジをご覧ください。
HTTP チャレンジまたは TLS-ALPN チャレンジを使用してドメイン名を検証する場合、クライアントは証明書に含まれるよう検証済みのドメイン名のみをリクエストできます。DNS チャレンジを使用する場合、クライアントはそのドメイン名のサブドメインをリクエストして証明書に含めるようリクエストすることもできます。
たとえば、DNS チャレンジを使用して *.myorg.example.com を検証すると、subdomain1.myorg.example.com と subdomain2.myorg.example.com が自動的にワイルドカード証明書の対象となります。ただし、HTTP チャレンジまたは TLS-ALPN チャレンジを使用して myorg.example.com を検証する場合は、クライアントは証明書に myorg.example.com を含めるようにリクエストすることしかできず、DNS 以外のチャレンジを使用して *.myorg.example.com を検証することはできません。
チャレンジ ソリューション ロジック
Public CA のチャレンジ ロジックは次のとおりです。
- Public CA はランダムなトークンを提供します。
- クライアントにより、明確に定義されたロケーションでトークンが使用可能になります。ロケーションはチャレンジによって異なります。
- クライアントは、チャレンジを準備したことを Public CA に知らせます。
- Public CA は、予想されるロケーションに存在するトークンが期待される値と一致するかどうかを確認します。
ドメイン名はこのプロセスの完了後に承認されます。クライアントはそのドメイン名を含む証明書をリクエストできます。1 つのドメイン名につき 1 つのチャレンジのみを解決する必要があります。