このページでは、Google マネージド証明書に対するドメインの承認の仕組みについて説明します。このページでは、ロードバランサの承認と DNS 認証を比較し、Certificate Manager が各メソッドを使用してドメインの所有権を確認する方法について説明します。
Certificate Manager を使用すると、次のいずれかの方法で、Google マネージド証明書を発行するドメインの所有権を確認できます。
ロードバランサの承認: DNS レコードを作成せずに、サポートされているロードバランサに証明書を直接デプロイします。この方法は構成が速いですが、ワイルドカード証明書やリージョン証明書はサポートしていません。また、Certificate Manager で証明書をプロビジョニングできるのは、ロードバランサが完全に設定され、ネットワーク トラフィックの処理が行われるようになった後です。
DNS 認証: ドメイン所有権の確認用の専用の DNS レコードを作成した後、サポートされているロードバランサに証明書を直接デプロイします。この方法では、ターゲット プロキシがネットワーク トラフィックを処理できるようになる前に、Certificate Manager で証明書を事前にプロビジョニングできます。
ドメインの承認は、Certificate Authority Service によって発行された Google マネージド証明書には適用されません。このような証明書の詳細については、Certificate Authority Service を使用してグローバル Google マネージド証明書をデプロイするをご覧ください。
ロードバランサ認証
ロードバランサ認証は、Google マネージド証明書を発行する最も簡単な方法です。この方法では DNS 構成への変更を最小限に抑えますが、TLS（SSL）証明書はロードバランサの構成が完了した後にのみプロビジョニングされます。この方法では、ロードバランサ認証が、既存の本番環境トラフィックのない新しい環境に最適です。
ロードバランサ認証を使用して Google マネージド証明書を作成するには、デプロイが次の要件を満たしている必要があります。
- ターゲット ドメインにサービスを提供するすべての IP アドレスからポート 443 で Google マネージド証明書にアクセスできる必要があります。そうしないと、プロビジョニングは失敗します。たとえば、IPv4 と IPv6 に個別のロードバランサがある場合は、それぞれに同じ Google マネージド証明書を割り当てる必要があります。
- DNS 構成でロードバランサの IP アドレスを明示的に指定する必要があります。これにより、多視点ドメイン検証の失敗を防ぐことができます。CDN などの中間レイヤが原因で、予期しない動作が発生する可能性があります。
- ターゲット ドメインは、インターネットから公開的に解決できる必要があります。スプリット ホライズン環境または DNS ファイアウォール環境は、証明書のプロビジョニングと干渉する可能性があります。
DNS 認証
DNS 認証を使用すると、本番環境が完全に設定される前に、ドメインの所有権を確認して Google マネージド証明書をプロビジョニングできます。これは、証明書を Google Cloudに移行する場合に特に便利です。
Certificate Manager は DNS レコードを使用してドメインの所有権を確認します。各 DNS 承認には、DNS レコードに関する情報が保存され、単一のドメインとそのワイルドカード（myorg.example.com と *.myorg.example.com の両方など）に対応しています。ワイルドカードは最初のサブドメイン レベルのみを対象とし、それより深いサブドメイン レベルは対象としません。たとえば、*.myorg.example.com は sub.subdomain.myorg.example.com をカバーしません。
Google マネージド証明書を作成するときに、1 つ以上の DNS 認証を使用して証明書をプロビジョニングして更新できます。1 つのドメインに複数の証明書がある場合は、すべての証明書に同じ DNS 認証を使用できます。ただし、DNS 認証は証明書にリストされているすべてのドメインを対象とする必要があります。対象としていない場合、証明書の作成と更新は失敗します。
DNS 認証を設定するには、DNS 構成に CNAME レコードを追加する必要があります。このレコードを使用して、ターゲット ドメインのサブドメインを検証できます。CNAME レコードは、Certificate Manager がドメインの所有権の確認に使用する特別な Google Cloud ドメインを参照します。DNS 認証を作成すると、Certificate Manager はこの CNAME レコードを返して所有権を確認します。
CNAME レコードは、Google Cloud プロジェクト内のターゲット ドメインの証明書のプロビジョニングと更新を行う権限も Certificate Manager に付与します。これらの権限を取り消すには、DNS 構成から CNAME レコードを削除します。
プロジェクトごとの DNS 認証
Google Cloud プロジェクトごとの DNS 認証を使用すると、各プロジェクト内で証明書を個別に管理できます。プロジェクトごとの DNS 認証を使用すると、Certificate Manager はプロジェクトごとに証明書を発行して処理できます。プロジェクト内で使用される DNS 認証と証明書は自己完結型であり、他のプロジェクトのアーティファクトとはやり取りしません。
プロジェクトごとの DNS 認証を有効にするには、DNS 認証を作成するときに PER_PROJECT_RECORD オプションを選択します。その後、サブドメインとそのプロジェクト固有のターゲットの両方を含む一意の CNAME レコードが返されます。この CNAME レコードは、関連するドメインの DNS ゾーンに追加する必要があります。
ロードバランサの認証と DNS 認証を比較する
Certificate Manager を使用すると、次の表に示すように、Google マネージド証明書を発行するドメインの所有権を確認できます。
| ロードバランサ認証 | DNS 認証 | |
|---|---|---|
| 設定の難易度 | ロードバランサの認証では、追加の構成手順や DNS 構成の変更は必要ありません。 | DNS 認証を作成し、対応する CNAME レコードを DNS 構成に追加する必要があります。 |
| ネットワーク セキュリティ | ロードバランサには、証明書によって提供されるすべてのドメインの DNS 構成を含め、ポート 443 でインターネットから完全にアクセス可能である必要があります。ロードバランサの認可は、他の構成では機能しません。 | 443 以外のポートやターゲット プロキシの前にある CDN レイヤなど、非常に複雑な構成で動作します。 |
| プロビジョニング速度 | 証明書のプロビジョニングは、ロードバランサが完全に設定され、ネットワーク トラフィックの処理が行われるようになった後にのみ行えます。 | ターゲット プロキシがネットワーク トラフィックを処理できるようになる前に、証明書をプロビジョニングできます。 |
| ワイルドカード証明書 | 非対応 | サポート対象 |