Certificate Manager は、環境内のドメイン名ごとに、割り当てる証明書とその提供方法をきめ細かく制御できる柔軟なマッピング メカニズムを使用します。このメカニズムには次のエンティティが含まれます。
- 証明書
- 証明書マップ
- 証明書マップエントリ
- ドメインの承認
次の図は、ロードバランサの転送ルールで指定された一般的なターゲット プロキシのこれらのエンティティ間の関係を示しています。
Certificate Manager は、ターゲット HTTPS プロキシとターゲット SSL プロキシをサポートしています。これらのプロキシタイプの違いについて詳しくは、ターゲット プロキシの使用をご覧ください。
Certificate Manager がサポートする証明書のタイプについては、デプロイの概要をご覧ください。
証明書
デフォルトでは、証明書は、特定のドメイン名またはドメイン ワイルドカードに対して発行される単一の X.509 Transport Layer Security（TLS）（SSL）証明書を表します。
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 つのトラスト アンカーと、必要に応じて 1 つ以上の中間証明書をカプセル化します。
トラスト アンカー
トラスト アンカーは、相互 TLS 認証シナリオで使用する単一のルート証明書を表します。トラストストア内にカプセル化されます。
中間証明書
中間証明書は、相互 TLS 認証のシナリオで使用するためにカプセル化されたトラストストアで参照される中間証明書またはルート証明書によって署名された単一の中間証明書を表します。
PKI 構成に応じて、1 つ以上の中間証明書をトラストストア内にカプセル化できます。信頼構成内で指定されたすべての中間証明書は、リクエスト自体で指定された中間証明書のリストに加えて、すべての接続リクエストの信頼評価の一部として含まれます。
許可リストを必要とする証明書
必要に応じて、自己署名された証明書、期限切れの証明書、その他の無効な証明書を使用する必要がある場合、またはルート証明書と中間証明書にアクセスできない場合は、その証明書を allowlistedCertificates フィールドの信頼構成に追加できます。証明書を許可リストに追加するためにトラストストアは必要ありません。
証明書を許可リストに追加すると、証明書が解析可能で、秘密鍵の所有の証明が確立され、証明書の SAN フィールドの制約が満たされている限り、証明書は常に有効とみなされます。
証明書の選択ロジック
大まかに言うと、ロードバランサは次のように証明書を選択します。
- クライアントが handshake を開始します。この手順では、handshake を実行するために使用できる暗号アルゴリズムのリストをロードバランサに提供します。必要に応じてホスト名を指定することもできます。
ロードバランサは、クライアントが提供するホスト名と構成済みの証明書マップのエントリに基づいて、セキュアな handshake を実行するための証明書を選択します。ロードバランサが選択する証明書は、次の要因によって決まります。
ホスト名が完全に一致する: クライアントがプロビジョニングされた証明書マップのエントリと完全に一致するホスト名を提供した場合、ロードバランサは対応する証明書を選択します。
ワイルドカードを含むホスト名が一致する: クライアントのホスト名がエントリとは一致しないが、証明書マップ エントリのワイルドカードを含むホスト名とは一致する場合、ロードバランサはこのエントリ内の対応する証明書を選択します。たとえば、
*.myorg.example.comとして構成されるワイルドカード エントリは、myorg.example.comドメインの第 1 レベルのサブドメインを対象とします。ホスト名は一致しないが、事前構成されたプライマリ証明書マップのエントリが一致する: ロードバランサは、ホスト名またはプロビジョニングされた証明書エントリの一致が見つからない場合、事前構成されたプライマリ証明書マップのエントリを選択します。
handshake が失敗する: 次の理由でロードバランサが一致する証明書を見つけられない場合、handshake は失敗します。
- クライアントが、プロビジョニングされたすべての証明書マップエントリで指定されたホスト名と完全一致しない、またはワイルドカードを含むホスト名と一致しないホスト名を提供しているか、ホスト名をまったく提供していない。
- 一致するプライマリ証明書マップのエントリが見つからないか、プライマリ証明書マップのエントリが構成されていない。
証明書の優先度
ロードバランサは、以下に基づいて証明書マップエントリ内の証明書を選択します。
- 証明書の種類。接続クライアントがより安全性の高い ECDSA 証明書をサポートしている場合、ロードバランサはこれらの証明書を RSA 証明書よりも優先します。クライアントが ECDSA 証明書のサポートを示していない場合、ロードバランサは代わりに RSA 証明書を提供します。
- 証明書のサイズ。ロードバランサでは、サイズが小さい証明書から大きい証明書への順に優先されます。
ワイルドカード ドメイン名
ワイルドカード ドメイン名には以下のルールが適用されます。
- ワイルドカード ドメイン名をサポートするのは、DNS 認証を使用した Google マネージド証明書と、CA Service を使用した 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 プロジェクトにリンクされているシークレットを使用して、各 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 つのチャレンジのみを解決する必要があります。