DNS 認証では、ドメイン所有権の証明のために専用の DNS レコードを追加で構成する必要がありますが、ターゲット プロキシがネットワーク トラフィックを処理できるようになる前に、証明書を事前にプロビジョニングできます。これにより、サードパーティ ソリューションから Google Cloudへのゼロ ダウンタイム移行が可能になります。
ロードバランサ認証
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 の両方など）に対応しています。
Google マネージド証明書を作成するときに、証明書のプロビジョニングと更新に 1 つ以上の DNS 認証を使用できます。1 つのドメインに複数の証明書がある場合は、それらすべてに同じ DNS 認証を使用できます。ただし、DNS 認証は証明書にリストされているすべてのドメインを対象とする必要があります。対象としていない場合、証明書の作成と更新は失敗します。
DNS 認証を設定するには、DNS 構成に CNAME レコードを追加する必要があります。このレコードは、ターゲット ドメインのサブドメインの検証に使用されます。CNAME レコードは、Certificate Manager がドメインの所有権の確認に使用する特別な Google Cloud ドメインを参照します。DNS 認証を作成すると、Certificate Manager はこの CNAME レコードを返して所有権を確認します。
Google Cloud プロジェクトごとの DNS 認証を使用すると、各プロジェクト内で証明書を個別に管理できます。プロジェクトごとの DNS 認証を使用すると、Certificate Manager はプロジェクトごとに証明書を発行して処理できます。プロジェクト内で使用される DNS 認証と証明書は自己完結型であり、他のプロジェクトのアーティファクトとやり取りしません。
プロジェクトごとの DNS 認証を有効にするには、DNS 認証を作成するときに PER_PROJECT_RECORD オプションを選択します。その後、サブドメインとそのプロジェクト固有のターゲットの両方を含む一意の CNAME レコードが生成されます。この CNAME レコードは、関連するドメインの DNS ゾーンに追加する必要があります。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-03-04 UTC。"],[[["\u003cp\u003eThis page details the two methods of domain authorization for Google-managed certificates: load balancer authorization and DNS authorization.\u003c/p\u003e\n"],["\u003cp\u003eLoad balancer authorization is quicker to configure but requires the load balancer to be fully set up and only works on port 443, while DNS authorization is more versatile by verifying domain ownership through DNS records and allows certificate provisioning in advance.\u003c/p\u003e\n"],["\u003cp\u003eDNS authorization enables the pre-provisioning of certificates before the production environment is live, and it's especially useful for migrating certificates to Google Cloud.\u003c/p\u003e\n"],["\u003cp\u003ePer-project DNS authorization allows each Google Cloud project to manage its certificates independently, with unique CNAME records for domain verification.\u003c/p\u003e\n"],["\u003cp\u003eUnlike load balancer and DNS authorization, domain authorization does not apply to Google-managed certificates issued by Certificate Authority Service.\u003c/p\u003e\n"]]],[],null,["# Domain authorization types for Google-managed certificates\n\nThis page describes how domain authorization works with Google-managed\ncertificates. The page compares load balancer authorization to DNS authorization\nand explains how Certificate Manager verifies domain ownership\nusing each method.\n\nCertificate Manager lets you prove ownership of domains for which\nyou want to issue Google-managed certificates in one of the following ways:\n\n- **Load balancer authorization**: deploy the certificate directly to a\n supported load balancer without creating a DNS record. This method is faster\n to configure, but it doesn't support wildcard certificates or regional\n certificates. Additionally, Certificate Manager can only\n provision certificates after the load balancer has been fully set up and is\n serving network traffic.\n\n- **DNS authorization**: deploy the certificate directly to a supported load\n balancer after creating dedicated DNS records for verification of domain\n ownership. Using this method, Certificate Manager can\n provision certificates in advance, before the target proxy is ready to serve\n network traffic.\n\nDomain authorization doesn't apply to Google-managed certificates issued by\nCertificate Authority Service. For more information about such certificates, see [Deploy a\nglobal Google-managed certificate with Certificate Authority Service](/certificate-manager/docs/deploy-google-managed-cas).\n\nLoad balancer authorization\n---------------------------\n\nLoad balancer authorization is the simplest method for issuing a Google-managed\ncertificate. This method minimizes changes to your DNS configuration, but only\nprovisions the TLS (SSL) certificate after the load balancer configuration is\ncomplete. This method also makes load balancer authorization ideal for new\nenvironments with no existing production traffic.\n\nTo create Google-managed certificates with load balancer authorization, your\ndeployment must meet the following requirements:\n\n- The Google-managed certificate must be accessible on port 443 from all IP addresses serving the target domain; otherwise, provisioning fails. For example, if you have separate load balancers for IPv4 and IPv6, you must assign the same Google-managed certificate to each of them.\n- You must explicitly specify the IP addresses of your load balancers in your DNS configuration, which prevents [multi-perspective domain validation\n failures](/certificate-manager/docs/troubleshooting#multi-perspective-domain-validation). Intermediate layers, such as CDN, can cause unpredictable behavior.\n- The target domain must be openly resolvable from the Internet. Split-horizon or DNS firewall environments can interfere with certificate provisioning.\n\nDNS authorization\n-----------------\n\nDNS authorization lets you verify domain ownership and provision Google-managed\ncertificates even before your production environment is fully set up. This is\nparticularly useful when you're migrating certificates to Google Cloud.\n\nCertificate Manager verifies domain ownership through DNS\nrecords. Each DNS authorization stores information about a DNS record, and\ncovers a single domain and its wildcard (for example, both `myorg.example.com`\nand `*.myorg.example.com`). A wildcard covers only the first subdomain level, and\ndoesn't cover deeper subdomain levels. For example, `*.myorg.example.com` doesn't cover\n`sub.subdomain.myorg.example.com`.\n\nWhen creating a Google-managed certificate, you can use one or more DNS\nauthorizations to provision and renew certificates. If you have\nmultiple certificates for a single domain, then you can use the same DNS\nauthorization for all the certificates. However, your DNS authorizations must cover all\ndomains listed in the certificate; if they don't, creating and renewing\ncertificates will fail.\n\nTo set up DNS authorization, you must add a `CNAME` record to your DNS\nconfiguration. You can use this record to validate the subdomain under your\ntarget domain. The `CNAME` record points to a special Google Cloud domain\nthat Certificate Manager uses to verify your domain ownership.\nWhen you create a DNS authorization, Certificate Manager returns\nthis `CNAME` record and verifies your ownership.\n\nRemember, the `CNAME` record also grants Certificate Manager\nthe permission to provision and renew certificates for the target domain within your\nGoogle Cloud project. To revoke these permissions, remove the CNAME record\nfrom your DNS configuration.\n| **Note:** The validation sub-domain must be openly resolvable from the internet. Split-horizon or DNS firewall environments can interfere with certificate provisioning.\n\n### Per-project DNS authorization\n\nPer-project DNS authorization lets you manage certificates independently within\neach Google Cloud project. Using per-project DNS authorization,\nCertificate Manager can issue and handle certificates for each\nproject separately. The DNS authorizations and certificates used within a\nproject are self-contained and don't interact with artifacts from other\nprojects.\n\nTo activate per-project DNS authorization, choose the `PER_PROJECT_RECORD`\noption when creating a DNS authorization. You will then receive a unique `CNAME`\nrecord that includes both a subdomain and a target specific to that project.\nYou shoud add this `CNAME` record to the DNS zone of the relevant domain.\n| **Note:** Due to ongoing IETF standardization efforts for account-based DNS authorization, Google uses a custom implementation of account-based DNS authorization for per-project DNS authorizations.\n\nCompare load balancer authorization with DNS authorization\n----------------------------------------------------------\n\nCertificate Manager lets you prove ownership of domains for which\nyou want to issue Google-managed certificates as described in the following\ntable.\n\nWhat's next\n-----------\n\n- [Manage DNS authorizations](/certificate-manager/docs/dns-authorizations)\n- [Deploy a global Google-managed certificate with load balancer\n authorization](/certificate-manager/docs/deploy-google-managed-lb-auth)\n- [Deploy a global Google-managed certificate with DNS authorization](/certificate-manager/docs/deploy-google-managed-dns-auth)"]]
