本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 驗證 AWS Certificate Manager 公有憑證的網域擁有權 AWS Certificate Manager (ACM) 必須證明您擁有或控制請求中指定的所有網域名稱，Amazon 憑證授權機構 (CA) 才能為您的網站發行憑證。當您請求憑證時，您可以選擇使用網域名稱系統 (DNS) 驗證、電子郵件驗證或 HTTP 驗證來證明擁有權。 **注意** 驗證僅適用於 ACM 發行的公開信任憑證。ACM 不會為[匯入的憑證](import-certificate.md)或由私有 CA 簽署的憑證驗證網域所有權。ACM 無法驗證 Amazon VPC [私有託管區域](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones)或任何其他私有網域中的資源。如需詳細資訊，請參閱[對憑證驗證進行故障診斷](certificate-validation.md)。 我們建議您在電子郵件驗證時使用 DNS 驗證，原因如下： + 如果您使用 Amazon Route 53 管理您的公有 DNS 記錄，可以直接透過 ACM 更新您的記錄。 + 只要憑證使用中，而且保有 CNAME 記錄，ACM 便會自動續約經 DNS 驗證的憑證。 + 電子郵件驗證的憑證需要網域擁有者續約 動作。ACM 開始在過期前 45 天傳送續約通知。這些通知會前往網域的五個常見管理員地址中的一個或多個。通知中包含網域擁有者可點選的連結，方便進行續約。驗證所有列出的網域後，ACM 會發行具有相同 ARN 的續約憑證。 如果您無法編輯網域的 DNS 資料庫，則必須改用[電子郵件驗證](email-validation.md)。 HTTP 驗證適用於與 CloudFront 搭配使用的憑證。此方法使用 HTTP 重新導向來證明網域擁有權，並提供類似於 DNS 驗證的自動續約。 **注意** 使用電子郵件驗證建立憑證之後，您無法切換為使用 DNS 進行驗證。若要使用 DNS 驗證，請刪除憑證，然後建立使用 DNS 驗證的新憑證。 **Topics** + [AWS Certificate Manager DNS 驗證](dns-validation.md) + [AWS Certificate Manager 電子郵件驗證](email-validation.md) + [AWS Certificate Manager HTTP 驗證](http-validation.md) # AWS Certificate Manager DNS 驗證 網域名稱系統 (DNS) 是一個目錄服務，適用於連接到網路的資源。您的 DNS 供應商會維護一個資料庫，其中包含定義您網域的記錄。當您選擇 DNS 驗證，ACM 會提供一或多個 CNAME 記錄，這些記錄必須新增至此資料庫中。這些記錄包含唯一的鍵值組，可作為您控制網域的證明。 **注意** 使用電子郵件驗證建立憑證之後，您無法切換為使用 DNS 進行驗證。若要使用 DNS 驗證，請刪除憑證，然後建立使用 DNS 驗證的新憑證。 例如，如果您為 `example.com` 網域請求憑證，並以 `www.example.com` 做為額外名稱，ACM 會為您建立兩筆 CNAME 記錄。每個專為您的網域和帳戶建立的記錄皆包含名稱和值。此值是指向 ACM 用來自動續約憑證的 AWS 網域的別名。必須將 CNAME 記錄新增到 DNS 資料庫一次。只要憑證使用中，而且保有 CNAME 記錄，ACM 便會自動續約憑證。 **重要** 如果您不是使用 Amazon Route 53 來管理公有 DNS 記錄，請聯絡您的 DNS 供應商以了解如何新增記錄。如果您沒有編輯網域 DNS 資料庫的授權，則必須改用[電子郵件驗證](email-validation.md)。 無需重複驗證，只要保有 CNAME 記錄，您就可以為完整網域名稱 (FQDN) 請求額外的 ACM 憑證。也就是說，您可以建立具有相同網域名稱的替代憑證，或建立涵蓋不同子網域的憑證。由於 CNAME 驗證字符適用於任何 AWS 區域，因此您可以在多個區域中重新建立相同的憑證。您也可以取代已刪除的憑證。 您可以從 AWS 服務移除相關聯的憑證或刪除 CNAME 記錄，以停止自動續約。如果您的 DNS 供應商不是 Route 53，請聯絡您的供應商，了解如何刪除記錄。如果您的供應商是 Route 53，請參閱 *Route 53 開發人員指南*中的[刪除資源記錄集](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-deleting.html)。如需受管的憑證續約的詳細資訊，請參閱「[中的受管憑證續約 AWS Certificate Manager](managed-renewal.md)」。 **注意** 如果您的 DNS 組態中有超過五個 CNAME 鏈結在一起，CNAME 解析將會失敗。如果您需要更長的鏈結，建議使用[電子郵件驗證](email-validation.md)。 ## ACM 的 CNAME 記錄運作方式 **注意** 本節適用於採用 Route 53 做為 DNS 供應商的客戶。 如果您不是使用 Route 53 做為 DNS 供應商，則需要手動將 ACM 提供的 CNAME 記錄輸入供應商的資料庫 (通常是透過網站操作)。CNAME 記錄用於許多用途，包括重新引導機制以及供應商專屬中繼資料的容器。對 ACM 來說，有了這些記錄，才能進行初始網域所有權驗證和持續自動化憑證續約。 下表顯示六個網域名稱的 CNAME 記錄範例。每筆記錄的**記錄名稱**-**記錄值**配對用於驗證網域名稱所有權。 請注意，在表格中，前兩個**記錄名稱**-**記錄值**配對是相同的。這說明了對於萬用字元網域，例如 `*.example.com`，ACM 建立的字串與其基本網域 建立的字串相同`example.com`。若非如此，每個網域名稱的配對**記錄名稱**和**記錄值**會有所不同。 **CNAME 記錄範例** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/acm/latest/userguide/dns-validation.html) 底線 ( \$1 ) 後的 *xN* 值為 ACM 產生的長字串。例如： ``` _3639ac514e785e898d2646601fa951d5.example.com. ``` 代表產生的**記錄名稱**。相關聯的**記錄值**可能是 ``` _98d2646601fa951d53639ac514e785e8.acm-validation.aws. ``` 針對相同的 DNS 記錄。 **注意** 如果您的 DNS 供應商不支援包含前置底線的 CNAME 值，請參閱[針對 DNS 驗證問題進行疑難排解](troubleshooting-DNS-validation.md)。 當您請求憑證並指定 DNS 驗證時，ACM 會以下列格式提供 CNAME 資訊： **** | 網域名稱 | 記錄名稱 | 記錄類型 | 記錄值 | | --- | --- | --- | --- | | example。com | \$1a79865eb4cd1a6ab990a45779b4e0b96.example.com。 | CNAME | \$1424c7224e9b0146f9a8808af955727d0.acm-validations.aws。 | *網域名稱*是憑證的相關聯 FQDN。*記錄名稱*為鍵值組的索引鍵，能唯一識別記錄。*記錄值*為鍵值組的值。 這三個值 (*Domain Name* (網域名稱)、*Record Name* (記錄名稱) 和 *Record Value* (記錄值)) 都必須輸入 DNS 供應商 Web 介面上用於新增 DNS 記錄的適用欄位中。供應商處理記錄名稱 (或單純「名稱」) 欄位的做法不一致。在某些情況下，您應該提供整個字符串，如上所示。其他供應商會自動將網域名稱附加到您輸入的任何字串中，這表示 (在本例中) 您應該只輸入 ``` _a79865eb4cd1a6ab990a45779b4e0b96 ``` 到名稱欄位中。如果您猜錯了，並輸入包含網域名稱 (例如 *`.example.com`*） 的記錄名稱，最終可能會產生以下結果： ``` _a79865eb4cd1a6ab990a45779b4e0b96.example.com.example.com. ``` 在這種情況下，驗證將會失敗。因此，您應該試著事先確定您的供應商所期望的輸入類型。 ## 設定 DNS 驗證 本節說明如何設定公有憑證以使用 DNS 驗證。 **在主控台上設定 DNS 驗證** **注意** 此程序假設您已建立至少一個憑證，而且您正在建立憑證的 AWS 區域中工作。如果您嘗試開啟主控台並改為看到第一次使用畫面，或者您成功開啟主控台，但未在清單中看到您的憑證，請確認您已指定正確的區域。 1. 前往 [https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/) 開啟 ACM 主控台。 1. 在憑證清單中，選擇具有您想要設定的 **Pending validation（待定驗證）**狀態的憑證之 **Certificate ID（憑證 ID）**。此動作會開啟憑證的詳細資料頁面。 1. 在 **Domains（網域）**部分中，完成下列兩個程序之一： 1. (選用) 使用 Route 53 進行驗證。 **Create records in Route 53（在 Route 53 中建立記錄）**按鈕會在符合以下情況時顯示： + 您使用 Route 53 做為 DNS 供應商。 + 您擁有寫入 Route 53 託管區域的許可。 + 您的 FQDN 未**經驗證。 **注意** 如果您實際上使用 Route 53，但 ** Route 53 中的建立記錄**遺失或停用，請參閱 [ACM 主控台未顯示「在 Route 53 中建立記錄」按鈕](troubleshooting-DNS-validation.md#troubleshooting-route53-1)。 選擇在 ** Route 53 中建立記錄**，然後選擇**建立記錄**。所以此 **Certificate status（憑證狀態）**頁面應該開啟並顯示狀態橫幅報告 **Successfully created DNS records（成功建立 DNS 記錄）**。 您的新憑證可能會繼續顯示 **Pending validation（待定驗證）**狀態最多 30 分鐘。 **提示** 您無法透過編寫程式的方式請求 ACM 自動在 Route 53 中建立記錄。不過，您可以對 Route 53 進行 AWS CLI 或 API 呼叫，以在 Route 53 DNS 資料庫中建立記錄。如需有關 Route 53 記錄集的詳細資訊，請參閱[使用 Route 53使用資源記錄集](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/rrsets-working-with.html)。 1. (選用) 如果您不是使用 Route 53 做為 DNS 供應商，您必須擷取 CNAME 資訊並新增至 DNS 資料庫。在新憑證的詳細資訊頁面上，您可透過以下兩種方式執行此操作： + 複製顯示在 **Domains（網域）**部分的 CNAME 元件。這些資訊需手動新增至 DNS 資料庫。 + 或者，選擇 **Export to CSV（匯出至 CSV）**。結果檔案中的資訊需手動新增至 DNS 資料庫。 **重要** 為避免驗證問題，請先檢閱「[ACM 的 CNAME 記錄運作方式](#cnames-overview)」，再將資訊新增至您 DNS 供應商的資料庫。如果您遇到問題，請參閱「[針對 DNS 驗證問題進行疑難排解](troubleshooting-DNS-validation.md)」。 如果 ACM 無法在為您產生 CNAME 值後的 72 小時內驗證網域名稱，ACM 會將憑證狀態變更為 **Validation timed out (驗證逾時)**。此結果最有可能的原因是您未使用 ACM 產生的值成功更新 DNS 組態。若要修正此問題，您必須在檢閱 CNAME 指示之後請求新憑證。 # AWS Certificate Manager 電子郵件驗證 AWS Certificate Manager (ACM) 必須驗證您擁有或控制請求中指定的所有網域，Amazon 憑證授權機構 (CA) 才能為您的網站發行憑證。您可以使用電子郵件或 DNS 執行驗證。此主題討論電子郵件驗證。 如果您在使用電子郵件驗證時遇到問題，請參閱[針對電子郵件驗證問題進行疑難排解](troubleshooting-email-validation.md)。 ## 電子郵件驗證的運作方式 ACM 會為每個網域傳送驗證電子郵件訊息到以下五個常見的系統電子郵件。或者，如果您想要改為在該網域接收這些電子郵件，您可以將超級網域指定為驗證網域。最小網站地址之前的任何子網域都是有效的，並在 之後用作電子郵件地址的網域`@`。例如，如果您將 example.com 指定為 的驗證網域，則可能會收到 admin@example.com 的電子郵件 subdomain.example.com 。 + administrator@your\$1domain\$1name + hostmaster@your\$1domain\$1name + postmaster@your\$1domain\$1name + webmaster@your\$1domain\$1name + admin@your\$1domain\$1name 若要證明您擁有網域，您必須選取這些電子郵件中包含的驗證連結。ACM 也會傳送驗證電子郵件到這些相同的地址，以在憑證過期後 45 天續約憑證。 使用 ACM API 或 CLI 對多網域憑證請求進行電子郵件驗證，會導致每個請求的網域傳送電子郵件訊息，即使請求包含請求中其他網域的子網域。網域擁有者必須先驗證每個網域的電子郵件訊息，ACM 才能發行憑證。 **此程序的例外情況** 如果您為開頭為 **www**或萬用字元星號 (**\$1**) 的網域名稱請求 ACM 憑證，ACM 會移除前置**www**或星號，並傳送電子郵件到管理地址。這些地址的形成方式是在網域名稱的剩餘部分加上 admin@、admin@、hostmaster@、postmaster@ 和 webmaster@。例如，如果您為 www.example.com 請求 ACM 憑證，則電子郵件會傳送到 admin@example.com，而非 admin@www.example.com。同樣地，如果您為 \$1.test.example.com 請求 ACM 憑證，則電子郵件會傳送到 admin@test.example.com。其餘的常用管理地址也是以類似方式形成。 **重要** ACM 不再支援新憑證或續約的 WHOIS 電子郵件驗證。常用系統地址仍受支援。如需詳細資訊，請參閱[部落格文章](https://aws.amazon.com/blogs/security/aws-certificate-manager-will-discontinue-whois-lookup-for-email-validated-certificates/)。 ## 考量事項 請遵循以下有關電子郵件驗證的注意事項。 + 您需要在您的網域中註冊一個有效的電子郵件地址，才能使用電子郵件驗證。設定電子郵件地址的程序不在本指南的說明範圍內。 + 驗證僅適用於 ACM 發行的公開信任憑證。ACM 不會為[匯入的憑證](import-certificate.md)或由私有 CA 簽署的憑證驗證網域所有權。ACM 無法驗證 Amazon VPC [私有託管區域](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones)或任何其他私有網域中的資源。如需詳細資訊，請參閱[對憑證驗證進行故障診斷](certificate-validation.md)。 + 使用電子郵件驗證建立憑證之後，您無法切換為使用 DNS 進行驗證。若要使用 DNS 驗證，請刪除憑證，然後建立使用 DNS 驗證的新憑證。 ## 憑證過期日期和續約 ACM 憑證的有效期為 198 天。續約憑證需要網域擁有者執行動作。ACM 會在過期前 45 天開始將續約通知傳送至與網域相關聯的電子郵件地址。通知包含網域擁有者可以按一下以進行續約的連結。驗證所有列出的網域後，ACM 會發行具有相同 ARN 的續約憑證。 ## （選用） 重新傳送驗證電子郵件 每封驗證電子郵件皆包含符記，可用於核准憑證要求。不過，因為核准流程所需的驗證電子郵件可能會遭垃圾郵件篩選器封鎖，或在傳輸中遺失，因此符記會在 72 小時後自動過期。如果您沒有收到原始電子郵件或符記已過期，您可以要求重新傳送電子郵件。如需如何重新傳送驗證電子郵件的資訊，請參閱 [重新傳送驗證電子郵件](email-renewal-validation.md#request-domain-validation-email-for-renewal) 若電子郵件驗證持續發生問題，請參閱[對 的問題進行故障診斷 AWS Certificate Manager](troubleshooting.md)中的[針對電子郵件驗證問題進行疑難排解](troubleshooting-email-validation.md)一節。 # 自動化 AWS Certificate Manager 電子郵件驗證 透過電子郵件驗證的 ACM 憑證通常需要網域擁有者手動操作。組織如需處理大量透過電子郵件驗證的憑證，可能會偏好建立可自動執行所需回應的剖析器。為了協助客戶使用電子郵件驗證，本節中的資訊說明用於網域驗證電子郵件訊息範本，以及完成驗證程序所涉及的工作流程。 ## 驗證電子郵件範本 驗證電子郵件訊息具有下列兩種格式之一，具體取決於要求新憑證還是續約現有憑證。反白顯示字串的內容應取代為待驗證網域的專屬值。 ### 驗證新憑證 電子郵件範本文字： ``` Greetings from Amazon Web Services, We received a request to issue an SSL/TLS certificate for requested_domain. Verify that the following domain, AWS account ID, and certificate identifier correspond to a request from you or someone in your organization. Domain: fqdn AWS account ID: account_id AWS Region name: region_name Certificate Identifier: certificate_identifier To approve this request, go to Amazon Certificate Approvals (https://region_name.acm-certificates.amazon.com/approvals?code=validation_code&context=validation_context) and follow the instructions on the page. This email is intended solely for authorized individuals for fqdn. To express any concerns about this email or if this email has reached you in error, forward it along with a brief explanation of your concern to validation-questions@amazon.com. Sincerely, Amazon Web Services ``` ### 驗證憑證以進行續約 電子郵件範本文字： ``` Greetings from Amazon Web Services, We received a request to issue an SSL/TLS certificate for requested_domain. This email is a request to validate ownership of the domain in order to renew the existing, currently in use, certificate. Certificates have defined validity periods and email validated certificates, like this one, require you to re-validate for the certificate to renew. Verify that the following domain, AWS account ID, and certificate identifier correspond to a request from you or someone in your organization. Domain: fqdn AWS account ID: account_id AWS Region name: region_name Certificate Identifier: certificate_identifier To approve this request, go to Amazon Certificate Approvals at https://region_name.acm-certificates.amazon.com/approvals?code=$validation_code&context=$validation_context and follow the instructions on the page. This email is intended solely for authorized individuals for fqdn. You can see more about how AWS Certificate Manager validation works here - https://docs.aws.amazon.com/acm/latest/userguide/email-validation.html. To express any concerns about this email or if this email has reached you in error, forward it along with a brief explanation of your concern to validation-questions@amazon.com. Sincerely, Amazon Web Services -- Amazon Web Services, Inc. is a subsidiary of Amazon.com, Inc. Amazon.com is a registered trademark of Amazon.com, Inc. This message produced and distributed by Amazon Web Services, Inc., 410 Terry Ave. North, Seattle, WA 98109-5210. (c)2015-2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Our privacy policy is posted at https://aws.amazon.com/privacy ``` 一旦您收到來自 的新驗證訊息 AWS，我們建議您將其用作剖析器up-to-date和授權範本。客戶若使用 2020 年 11 月之前設計的訊息剖析器，應注意可能已對範本進行下列變更： + 電子郵件主旨行現在為「`Certificate request for domain name`」而不是「`"Certificate approval for domain name`」。 + `AWS account ID` 現在會以不含破折號或連字號的形式呈現。  + `Certificate Identifier` 現在呈現了整個憑證 ARN 而不是縮短的形式，例如，`arn:aws:acm:us-east-1:000000000000:certificate/3b4d78e1-0882-4f51-954a-298ee44ff369` 而不是 `3b4d78e1-0882-4f51-954a-298ee44ff369`。 + 憑證核准 URL 現在包含 `acm-certificates.amazon.com` 而不是 `certificates.amazon.com`。 + 按一下憑證核准 URL 所開啟的核准表單現在包含核准按鈕。核准按鈕 div 的名稱現在是 `approve-button` 而不是 `approval_button`。 + 新請求的憑證和續約憑證的驗證訊息使用相同的電子郵件格式。 ## 驗證工作流程 本節提供電子郵件驗證憑證的續約工作流程的相關資訊。 + 當 ACM 主控台處理多網域憑證請求時，它會傳送驗證電子郵件訊息到您請求公有憑證時指定的網域名稱或驗證網域。網域擁有者必須先驗證每個網域的電子郵件訊息，ACM 才能發行憑證。如需詳細資訊，請參閱[使用電子郵件驗證網域所有權](https://docs.aws.amazon.com/acm/latest/userguide/email-validation.html)。 + 使用 ACM API 或 CLI 對多網域憑證請求進行電子郵件驗證，會導致每個請求的網域傳送電子郵件訊息，即使請求包含請求中其他網域的子網域。網域擁有者必須先驗證每個網域的電子郵件訊息，ACM 才能發行憑證。 如果您透過 ACM 主控台重新傳送電子郵件給現有憑證，電子郵件會傳送至原始憑證請求中指定的驗證網域，如果未指定驗證網域，則會傳送至確切的網域。若要在不同的網域接收驗證電子郵件，您可以請求新的憑證，指定要用於驗證的驗證網域。或者，您可以使用 API、 SDK 或 CLI 使用 `ValidationDomain` 參數呼叫 [ResendValidationEmail](https://docs.aws.amazon.com/acm/latest/APIReference/API_ResendValidationEmail.html)。不過，`ResendValidationEmail`請求中指定的驗證網域僅用於該呼叫，不會儲存到憑證 Amazon Resource Name (ARN) 以供未來驗證電子郵件使用。每次您想要以原始憑證請求中未指定的網域名稱接收驗證電子郵件`ResendValidationEmail`時，都必須呼叫 。 **注意** 在 2020 年 11 月之前，客戶只需要驗證頂層網域，ACM 就會發行同樣涵蓋任何子網域的憑證。在該時間之前設計訊息剖析器的客戶，應注意電子郵件驗證工作流程有所變更。 + 使用 ACM API 或 CLI 時，您可以強制將多網域憑證請求的所有驗證電子郵件訊息傳送至頂層網域。在 API 中，使用 [RequestCertificate](https://docs.aws.amazon.com/acm/latest/APIReference/API_RequestCertificate.html) 動作的 `DomainValidationOptions` 參數來指定 `ValidationDomain` 的值，其為 [DomainValidationOption](https://docs.aws.amazon.com/acm/latest/APIReference/API_DomainValidationOption.html) 類型的成員。在 CLI 中，使用 [request-certificate](https://docs.aws.amazon.com/cli/latest/reference/acm/request-certificate.html) 命令的 **--domain-validation-options** 參數來指定 `ValidationDomain` 的值。 # AWS Certificate Manager HTTP 驗證 超文字傳輸通訊協定 (HTTP) 是全球資訊網上資料通訊的基礎通訊協定。當您為與 CloudFront 搭配使用的憑證選擇 HTTP 驗證時，ACM 會利用此通訊協定來驗證您的網域擁有權。ACM 可與 CloudFront 搭配使用，為您提供特定的 URL 和唯一的權杖，該權杖必須在網域上的該 URL 上進行存取。此字符可做為您控制網域的證明。透過設定從網域重新導向至 CloudFront 基礎設施內的 ACM 控制位置，您可以示範修改網域上內容的能力，藉此驗證您的擁有權。ACM 和 CloudFront 之間的無縫整合可簡化憑證發行程序，尤其是 CloudFront 分發。 **重要** HTTP 驗證不支援萬用字元網域憑證 （例如 \$1.example.com)。對於萬用字元憑證，您必須改用 DNS 驗證或電子郵件驗證。 例如，如果您使用 CloudFront 為 `example.com` 網域請求憑證`www.example.com`作為額外的名稱，ACM 會為您提供兩組 URLs以進行 HTTP 驗證。每個集合都包含 `redirectFrom` URL 和 `redirectTo` URL，專為您的網域和 AWS 帳戶建立。`redirectFrom` URL 是您網域上需要設定的路徑 （例如 `http://example.com/.well-known/pki-validation/example.txt`)。`redirectTo` URL 指向 CloudFront 基礎設施中存放唯一驗證字符的 ACM 控制位置。您只需要設定這些重新導向一次。當憑證授權機構嘗試驗證您的網域擁有權時，它會從 `redirectFrom` URL 請求檔案，CloudFront 會將該 URL 重新導向至 `redirectTo` URL，以允許存取驗證字符。只要憑證與 CloudFront 搭配使用，且您的重新導向仍然存在，ACM 就會自動續約您的憑證。 使用 CloudFront 為完整網域名稱 (FQDN) 設定 HTTP 驗證後，您可以為該 FQDN 請求額外的 ACM 憑證，而無需重複驗證程序，只要 HTTP 重新導向仍然存在。這表示您可以使用相同的網域名稱建立替代憑證。如果重新導向仍處於作用中狀態，您也可以取代已刪除的憑證，而無需再次進行驗證程序。 若要停止 HTTP 驗證憑證的自動續約，您有兩個選項。您可以從與其相關聯的 CloudFront 分佈中移除憑證，也可以刪除您設定用於驗證的 HTTP 重新導向。如果您使用 CloudFront 以外的內容交付網路 (CDN) 或 Web 伺服器來管理重新導向，請參閱其文件以了解如何移除重新導向。如果您使用 CloudFront 來管理重新導向，您可以透過更新分佈的組態來移除重新導向。如需受管的憑證續約的詳細資訊，請參閱「[中的受管憑證續約 AWS Certificate Manager](managed-renewal.md)」。請記住，停止自動續約可能會導致憑證過期，這可能會中斷您的 HTTPS 流量。 ## ACM 的 HTTP 重新導向如何運作 **注意** 本節適用於使用 CloudFront 進行內容交付和 ACM 進行 SSL/TLS 憑證管理的客戶。 搭配 ACM 和 CloudFront 使用 HTTP 驗證時，您需要設定 HTTP 重新導向。這些重新導向可讓 ACM 驗證您的網域擁有權，以進行初始憑證發行和持續自動續約。重新導向機制的運作方式是將網域上的特定 URL 指向 CloudFront 基礎設施中存放唯一驗證字符的 ACM 控制位置。 下表顯示網域名稱的重新導向組態範例。請注意，HTTP 驗證不支援萬用字元網域 （例如 \$1.example.com)。每個組態的**重新導向自****重新導向至** 對都可用來驗證網域名稱擁有權。 **HTTP 重新導向組態範例** | 網域名稱 | 從 重新導向 | 重新導向至 | Comment | | --- | --- | --- | --- | | example。com | `http://example.com/.well-known/pki-validation/x2.txt` | `https://validation.region.acm-validations.aws/y2/.well-known/pki-validation/x2.txt` | 唯一 | | www.example.com | `http://www.example.com/.well-known/pki-validation/x3.txt` | `https://validation.region.acm-validations.aws/y3/.well-known/pki-validation/x3.txt` | 唯一 | | host.example.com | `http://host.example.com/.well-known/pki-validation/x4.txt` | `https://validation.region.acm-validations.aws/y4/.well-known/pki-validation/x4.txt` | 唯一 | | subdomain.example.com | `http://subdomain.example.com/.well-known/pki-validation/x5.txt` | `https://validation.region.acm-validations.aws/y5/.well-known/pki-validation/x5.txt` | 唯一 | | host.subdomain.example.com | `http://host.subdomain.example.com/.well-known/pki-validation/x6.txt` | `https://validation.region.acm-validations.aws/y6/.well-known/pki-validation/x6.txt` | 唯一 | 檔案名稱中的 *xN* 值和 ACM 控制網域中的 *yN* 值是 ACM 產生的唯一識別符。例如 ``` http://example.com/.well-known/pki-validation/3639ac514e785e898d2646601fa951d5.txt ``` 代表產生的**重新導向來源** URL。關聯的**重新導向至** URL 可能是 ``` https://validation.region.acm-validations.aws/98d2646601fa/.well-known/pki-validation/3639ac514e785e898d2646601fa951d5.txt ``` 相同的驗證記錄。 **注意** 如果您的 Web 伺服器或內容交付網路不支援在指定路徑設定重新導向，請參閱[對 HTTP 驗證問題進行故障診斷](troubleshooting-HTTP-validation.md)。 當您請求憑證並指定 HTTP 驗證時，ACM 會以下列格式提供重新導向資訊： **** | 網域名稱 | 從 重新導向 | 重新導向至 | | --- | --- | --- | | example。com | http://example.com/.well-known/pki-validation/a79865eb4cd1a6ab990a45779b4e0b96.txt | https://validation.region.acm-validations.aws/a424c7224e9b/.well-known/pki-validation/a79865eb4cd1a6ab990a45779b4e0b96.txt | *網域名稱*是憑證的相關聯 FQDN。*Redirect From* 是您網域上的 URL，ACM 會在其中尋找驗證檔案。*重新導向至* 是託管實際驗證檔案的 ACM 控制 URL。 您需要設定 Web 伺服器或 CloudFront 分佈，將請求從*重新導向自 URL *重新導向至*重新導向至* URL。設定此重新導向的確切方法取決於您的 Web 伺服器軟體或 CloudFront 組態。確保正確設定重新導向，以允許 ACM 驗證您的網域擁有權，並發行或續約您的憑證。 ## 設定 HTTP 驗證 ACM 在發行公有 SSL/TLS 憑證以搭配 CloudFront 使用時，會使用 HTTP 驗證來驗證您的網域擁有權。本節說明如何設定公有憑證以使用 HTTP 驗證。 **在主控台中設定 HTTP 驗證** **注意** 此程序假設您已透過 CloudFront 請求憑證，而且您正在建立憑證的 AWS 區域中工作。HTTP 驗證只能透過 CloudFront 分佈租用戶功能使用。 1. 前往 [https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/) 開啟 ACM 主控台。 1. 在憑證清單中，選擇具有您想要設定的 **Pending validation（待定驗證）**狀態的憑證之 **Certificate ID（憑證 ID）**。此動作會開啟憑證的詳細資料頁面。 1. 在**網域**區段中，您可以查看憑證請求中每個網域的**重新導向來源**和**重新導向至**值。 1. 對於每個網域，設定從 **URL 重新導向**至 URL 的 HTTP **重新導向**。您可以透過 CloudFront 分佈組態執行此操作。 1. 設定您的 CloudFront 分佈，將請求從**重新導向自 URL **重新導向至**重新導向至** URL。設定此重新導向的方法取決於您的 CloudFront 組態。 1. 設定重新導向之後，ACM 會自動嘗試驗證您的網域擁有權。此程序最多需要 30 分鐘的時間。 如果 ACM 無法在為您產生重新導向值的 72 小時內驗證網域名稱，ACM 會將憑證狀態變更為**驗證逾時**。此結果最可能的原因是您未成功設定 HTTP 重新導向。若要修正此問題，您必須在檢閱重新導向指示後請求新的憑證。 **重要** 為了避免驗證問題，請確定**重新導向來源**位置的內容與**重新導向至**位置的內容相符。如果您遇到問題，請參閱[故障診斷 HTTP 驗證問題](troubleshooting-HTTP-validation.md)。 **注意** 與 DNS 驗證不同，您無法以程式設計方式請求 ACM 自動建立 HTTP 重新導向。您必須透過 CloudFront 分佈設定來設定這些重新導向。 如需 HTTP 驗證如何運作的詳細資訊，請參閱 [ACM 的 HTTP 重新導向如何運作](#http-redirects-overview)。