負載平衡器授權是發出 Google 管理憑證的最簡單方法。這種方法可盡量減少 DNS 設定的變更，但只會在負載平衡器設定完成後才佈建 TLS (SSL) 憑證。這種方法也讓負載平衡器授權功能非常適合沒有現有正式版流量的新環境。
如要建立具備負載平衡器授權的 Google 代管憑證，您的部署作業必須符合下列條件：
所有提供目標網域的 IP 位址都必須透過通訊埠 443 存取 Google 代管的憑證，否則佈建作業會失敗。舉例來說，如果您為 IPv4 和 IPv6 分別設定負載平衡器，就必須為每個負載平衡器指派相同的 Google 管理憑證。
您必須在 DNS 設定中明確指定負載平衡器的 IP 位址，以免發生多重觀點網域驗證失敗。CDN 等中介層可能會導致無法預測的行為。
目標網域必須是可從網際網路公開解析的網域。水平分割或 DNS 防火牆環境可能會干擾憑證佈建作業。
DNS 授權
您可以在實際工作環境尚未完全設定完成前，透過 DNS 授權驗證網域擁有權，並佈建 Google 管理的憑證。這在將憑證遷移至 Google Cloud時特別實用。
憑證管理工具會透過 DNS 記錄驗證網域擁有權。每個 DNS 授權都會儲存 DNS 記錄的相關資訊，並涵蓋單一網域及其萬用字元 (例如 myorg.example.com 和 *.myorg.example.com)。萬用字元只涵蓋第一個子網域層級，不涵蓋更深層的子網域層級。例如，*.myorg.example.com 不涵蓋 sub.subdomain.myorg.example.com。
建立 Google 代管的憑證時，您可以使用一或多個 DNS 授權來佈建及續購憑證。如果單一網域有多個憑證，您可以為所有憑證使用相同的 DNS 授權。不過，DNS 授權必須涵蓋憑證中列出的所有網域；如果不涵蓋，則建立和續發憑證會失敗。
如要設定 DNS 授權，您必須在 DNS 設定中新增 CNAME 記錄。您可以使用這個記錄驗證目標網域下的子網域。CNAME 記錄會指向 Certificate Manager 用來驗證網域擁有權的特殊 Google Cloud 網域。建立 DNS 授權時，憑證管理工具會傳回這個 CNAME 記錄，並驗證您的擁有權。
請注意，CNAME 記錄也會授予憑證管理工具在Google Cloud 專案中為目標網域設定和續訂憑證的權限。如要撤銷這些權限，請從 DNS 設定中移除 CNAME 記錄。
依專案 DNS 授權
依專案 DNS 授權可讓您在各 Google Cloud 專案中獨立管理憑證。使用個別專案 DNS 授權，憑證管理工具就能分別為每個專案核發及處理憑證。專案中使用的 DNS 授權和憑證是自給自足的，不會與其他專案的構件互動。
如要啟用個別專案的 DNS 授權，請在建立 DNS 授權時選擇 PER_PROJECT_RECORD 選項。接著，您會收到不重複的 CNAME 記錄，其中包含子網域和專屬於該專案的目標。您應將此 CNAME 記錄新增至相關網域的 DNS 區域。
比較負載平衡器授權與 DNS 授權
憑證管理工具可讓您證明要核發 Google 管理憑證的網域擁有權，如下表所述。
負載平衡器授權
DNS 授權
設定複雜度
負載平衡器授權不需要額外的設定步驟，也不需要變更 DNS 設定。
需要建立 DNS 授權，並在 DNS 設定中新增對應的 CNAME 記錄。
網路安全
負載平衡器必須透過通訊埠 443 從網際網路完全存取，包括憑證所服務的所有網域的 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-09-04 (世界標準時間)。"],[[["\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)"]]
