本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 验证 AWS Certificate Manager 公有证书的域名所有权 在 Amazon 证书颁发机构 (CA) 能够为您的网站颁发证书以前， AWS Certificate Manager (ACM) 必须先确认您拥有或可以控制请求中指定的所有域名。在申请证书时，您可以选择通过域名系统 (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 更新您的记录。 + 只要证书正在使用中，并且别名记录保持存在，ACM 就会自动续订 DNS 验证的证书。 + 通过电子邮件验证的证书需要域拥有者执行操作才能续订。ACM 会在到期前 45 天开始发送续订通知。这些通知将发送到该域的五个常用管理员地址中的一个或多个地址。通知中包含一个链接，域拥有者可以单击该链接以轻松续订。验证所有列出的域后，ACM 会颁发具有相同 ARN 的续订证书。 如果您无法编辑域的 DNS 数据库，则必须使用[电子邮件验证](email-validation.md)。 HTTP 验证适用于与一起使用的证书 CloudFront。此方法使用 HTTP 重定向来证明域所有权，并提供类似于 DNS 验证的自动续订。 **注意** 在创建采用电子邮件验证的证书后，您无法切换到使用 DNS 对其进行验证。要使用 DNS 验证，请删除该证书，然后创建一个使用 DNS 验证的新证书。 **Topics** + [AWS Certificate Manager 域名系统验证](dns-validation.md) + [AWS Certificate Manager 电子邮件验证](email-validation.md) + [AWS Certificate Manager HTTP 验证](http-validation.md) # AWS Certificate Manager 域名系统验证 域名系统 (DNS) 是连接到网络的资源的目录服务。DNS 提供商维护一个包含定义域的记录的数据库。如果选择 DNS 验证，ACM 会提供一条或多条别名记录，这些记录必须添加到此数据库。这些记录包含一个唯一的键值对，用于证明您对该域具有控制权。 **注意** 在创建采用电子邮件验证的证书后，您无法切换到使用 DNS 对其进行验证。要使用 DNS 验证，请删除该证书，然后创建一个使用 DNS 验证的新证书。 例如，如果为 `example.com` 域请求证书并指定 `www.example.com` 为其他名称，则 ACM 为您创建两条别名记录。每条记录都是专为您的域和账户创建的，包含名称和值。该值是一个别名，指向 ACM 用来自动续订您的证书的 AWS 域。别名记录只需添加到 DNS 数据库中一次。只要证书正在使用中，并且别名记录保持存在，ACM 就会自动续订证书。 **重要** 如果您使用 Amazon Route 53 管理您的公有 DNS 记录，请联系您的 DNS 提供商了解如何添加记录。如果您没有编辑域的 DNS 数据库的权限，则必须使用[电子邮件验证](email-validation.md)。 无需重复验证，只要别名记录仍然存在，您就可以为您的完全限定域名 (FQDN) 申请额外的 ACM 证书。也就是说，您可以创建具有相同域名的替换证书，或者是覆盖不同子域的证书。由于 CNAME 验证令牌适用于任何 AWS 区域，因此您可以在多个区域中重新创建相同的证书。您还可以替换已删除的证书。 您可以通过从证书关联的 AWS 服务删除证书或通过删除别名记录来停止自动续订。如果您的 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 配置中链接了五个以上的别名 CNAMEs 记录，CNAME 解析就会失败。如果您需要更长的链接，我们建议使用[电子邮件验证](email-validation.md)。 ## ACM 别名记录的工作原理 **注意** 本部分适用于不使用 Route 53 作为其 DNS 提供商的客户。 如果您不使用 Route 53 作为 DNS 提供商，则需要（通常通过网站）手动将 ACM 提供的别名记录输入到提供商的数据库中。别名记录用于多种目的，包括作为重新导向机制和供应商特定元数据的容器。对于 ACM，这些记录允许初始域所有权验证和持续的自动证书续订。 下表显示了六个域名的示例别名记录。每条记录的**记录名称**-**记录值**对用于验证域名所有权。 在表中，请注意，前两个**记录名称**-**记录值**对是相同的。这说明了对于 `*.example.com` 等通配符域，ACM 创建的字符串与为其基域 `example.com` 创建的字符串相同。否则，配对的**记录名称**和**记录值**将会因每个域名而异。 **别名记录示例** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/acm/latest/userguide/dns-validation.html) 下划线 (\$1) 之后的*xN*值是 ACM 生成的长字符串。例如， ``` _3639ac514e785e898d2646601fa951d5.example.com. ``` 代表生成的**记录名称**。关联的**记录值**可能是 ``` _98d2646601fa951d53639ac514e785e8.acm-validation.aws. ``` 用于同一 DNS 记录。 **注意** 如果您的 DNS 提供商不支持带有前导下划线的别名记录值，请参阅[排查 DNS 验证问题](troubleshooting-DNS-validation.md)。 当您请求证书并指定 DNS 验证时，ACM 会提供以下格式的别名记录信息： **** | 域名 | 记录名称 | 记录类型 | 记录值 | | --- | --- | --- | --- | | example.com | \$1a79865eb4cd1a6ab990a45779b4e0b96.example.com。 | 别名记录 | \$1424c7224e9b0146f9a8808af955727d0.acm-validations.aws。 | *域名*是与证书关联的 FQDN。*记录名称*唯一标识记录，用作键值对的键。*记录值*用作键值对的值。 必须在 DNS 提供商用于添加 DNS 记录的 Web 界面的相应字段中输入所有这三个值（*域名*、*记录名称*和*记录值*）。提供商对于记录名称（或只是“名称”）字段的处理方式并不相同。在某些情况下，您需要提供上面所示的整个字符串。其他提供商会自动将域名附加到您输入的任何字符串，这意味着（在本示例中）您只应输入 ``` _a79865eb4cd1a6ab990a45779b4e0b96 ``` 到名称字段中。如果您猜错了这一点，并输入包含域名的记录名称（例如 *`.example.com`*），您的最终结果可能如下所示： ``` _a79865eb4cd1a6ab990a45779b4e0b96.example.com.example.com. ``` 在这种情况下，验证将失败。因此，您应该尝试提前确定您的提供商期望的输入类型。 ## 设置 DNS 验证 此部分介绍如何将公有证书配置为使用 DNS 验证。 **在控制台中设置 DNS 验证** **注意** 此过程假设您已经创建了至少一个证书，并且您正在创建该证书的 AWS 地区工作。如果您尝试打开控制台并看到首次使用屏幕，或者您已成功打开控制台，但没有在列表中看到您的证书，请确认您指定了正确的区域。 1. 打开 ACM 控制台，网址为。[https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/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 但 **Create record in Route 53**（在 Route 53 中创建记录）缺失或已禁用，请参阅 [ACM 控制台不显示“Create record in Route 53”（在 Route 53 中创建记录）按钮](troubleshooting-DNS-validation.md#troubleshooting-route53-1)。 选择 **Create records in Route 53**（在 Route 53 中创建记录），然后选择 **Create records**（创建记录）。此时会打开 **Certificate status**（证书状态）页面，状态横幅将报告 **Successfully created DNS records**（已成功创建 DNS 记录）。 您的新证书可能会继续显示 **Pending validation**（等待验证）最多 30 分钟。 **提示** 您无法以编程方式请求 ACM 在 Route 53 中自动创建您的记录。但是，您可以对 Route 53 进行 AWS CLI 或 API 调用，在 Route 53 的 DNS 数据库中创建记录。有关 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 别名记录的工作原理](#cnames-overview) 然后将信息添加到 DNS 提供商的数据库。如果遇到问题，请参阅 [排查 DNS 验证问题](troubleshooting-DNS-validation.md)。 如果 ACM 无法在生成别名记录值后的 72 小时内验证域名，ACM 会将证书状态更改为 **Validation timed out（验证超时）**。导致此结果的最可能原因是您未使用 ACM 生成的值成功更新 DNS 配置。要解决此问题，您必须在查看别名记录说明后请求新的证书。 # AWS Certificate Manager 电子邮件验证 AWS Certificate Manager (ACM) 必须先确认您拥有或可以控制请求中指定的所有域，然后 Amazon 证书颁发机构 (CA) 才能为网站颁发证书。您可以使用电子邮件或 DNS 执行验证。本主题讨论电子邮件验证。 如果在使用电子邮件验证时遇到问题，请参阅[排查电子邮件验证的问题](troubleshooting-email-validation.md)。 ## 电子邮件验证的工作原理 对于每个域，ACM 都会将验证电子邮件发送到以下五个常用系统电子邮件地址。如果您希望改为通过该域接收这些电子邮件，则可以将某个超级域指定为验证域。不超过最小网站地址的任何子域都有效，并且会作为 `@` 符号之后的后缀用作电子邮件地址域。例如，假设将 example.com 指定为 subdomain.example.com 的验证域，则可能会收到一封发送至 admin@example.com 的电子邮件。 + administrator@your\$1domain\$1name + hostmaster@your\$1domain\$1name + postmaster@your\$1domain\$1name + webmaster@your\$1domain\$1name + admin@your\$1domain\$1name 要证明您拥有该域的所有权，必须选择这些电子邮件中包含的验证链接。在证书到期前 45 天，ACM 还会向这些地址发送验证电子邮件以续订证书。 对于使用 ACM API 或 CLI 的多域证书请求，进行电子邮件验证会导致每个请求的域都会发送一封电子邮件，即使该请求中包含其他域的子域。域拥有者需要验证每个域的电子邮件消息，然后 ACM 才能颁发证书。 **此过程的例外情况** 如果您为以 **www** 或星号通配符 (**\$1**) 开头的域名请求 ACM 证书，则 ACM 将删除开头的 **www** 或星号，并将电子邮件发送到管理地址。这些地址的格式是在域名的剩余部分前面添加 admin@、administrator@、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 控制台重新发送现有证书的电子邮件，则该电子邮件将发送到原始证书请求中指定的验证域，如果未指定验证域，则将发送到所请求的域。要通过其他域接收验证电子邮件，您可以申请新证书，指定要用于验证的验证域。或者，您可以[ResendValidationEmail](https://docs.aws.amazon.com/acm/latest/APIReference/API_ResendValidationEmail.html)使用 API、SDK 或 CLI 使用`ValidationDomain`参数进行调用。但是，`ResendValidationEmail` 请求中指定的验证域仅用于该此调用，不会保存到证书的 Amazon 资源名称（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) 是在万维网上进行数据通信的基础协议。当您为使用的证书选择 HTTP 验证时 CloudFront，ACM 会利用此协议来验证您的域所有权。ACM 与配合使用 CloudFront ，为您提供特定 URL 和唯一令牌，您网域上的该 URL 必须允许访问这些令牌。此令牌可证明您对该域具有控制权。通过在 CloudFront 基础架构中设置从您的域名重定向到 ACM 控制的位置，您可以证明自己有能力修改域上的内容，从而验证您的所有权。ACM 之间的这种无缝集成 CloudFront简化了证书颁发流程，尤其是对于 CloudFront 分发而言。 **重要** HTTP 验证不支持通配符域证书（例如 \$1.example.com）。对于通配符证书，必须改用 DNS 验证或电子邮件验证。 例如，如果您使用请求`example.com`域的证书`www.example.com`作为附加名称 CloudFront，ACM 会为您提供两组用 URLs 于 HTTP 验证的证书。每组都包含一个 `redirectFrom` URL 和一个 `redirectTo` URL，专为您的域和 AWS 账户创建。`redirectFrom` URL 是您需要配置的域（例如 `http://example.com/.well-known/pki-validation/example.txt`）上的路径。该 `redirectTo` URL 指向 CloudFront 基础设施中存储唯一验证令牌的 ACM 控制位置。您只需设置这些重定向一次即可。当证书颁发机构尝试验证您的域名所有权时，它将请求来自网址的文件，`redirectFrom`网址会 CloudFront 重定向到`redirectTo`网址，从而允许访问验证令牌。只要证书正在使用并且您的重定向仍然有效，ACM 就会自动 CloudFront 续订您的证书。 使用为完全限定域名 (FQDN) 设置 HTTP 验证后 CloudFront，只要仍存在 HTTP 重定向，您就可以为该 FQDN 申请其他 ACM 证书，而无需重复验证过程。这意味着您可以使用相同的域名创建替换证书。只要重定向仍处于活动状态，您也可以替换已删除的证书，而无需再次进行验证过程。 要停止自动续订 HTTP 验证的证书，您有两个选择。您可以将证书从与其关联的 CloudFront 分配中删除，也可以删除为验证而设置的 HTTP 重定向。如果您使用内容分发网络 (CDN) 或 Web 服务器 CloudFront 来管理重定向，请查阅他们的文档以了解如何删除重定向。如果您使用 CloudFront 管理重定向，则可以通过更新分配的配置来删除重定向。有关托管证书续订的更多信息，请参阅[中的托管证书续订 AWS Certificate Manager](managed-renewal.md)。请记住，停止自动续订可能会导致证书过期，造成您的 HTTPS 流量中断。 ## ACM 的 HTTP 重定向的工作原理 **注意** 本部分 CloudFront 适用于使用内容交付和 ACM 进行 SSL/TLS 证书管理的客户。 在 ACM 和中使用 HTTP 验证时 CloudFront，您需要设置 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` | Unique | | 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` | Unique | | 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` | Unique | | 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` | Unique | | 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` | Unique | 文件名中的*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/a 79865eb4cd1a6ab990a45779b4e0b96.txt | https://validation。 region.acm-validations.aws/ /.well-known/pki-a424c7224e9b validation/.txt a79865eb4cd1a6ab990a45779b4e0b96 | *域名*是与证书关联的 FQDN。*重定向自*是您域上的 URL，ACM 将在其中查找验证文件。*重定向至*是托管实际验证文件的 ACM 控制 URL。 您需要将 Web 服务器或 CloudFront 分发版本配置为将请求从 “重定向自” URL *重定**向到 URL 重定向*。设置此重定向的确切方法取决于您的 Web 服务器软件或 CloudFront 配置。确保重定向设置正确，以允许 ACM 验证您的域所有权并颁发或续订您的证书。 ## 设置 HTTP 验证 在颁发用于的公共 SSL/TLS 证书时，ACM 使用 HTTP 验证来验证您的域所有权。 CloudFront此部分介绍如何将公有证书配置为使用 HTTP 验证。 **在控制台中设置 HTTP 验证** **注意** 此过程假设您已经通过申请了证书， CloudFront 并且您正在创建证书的 AWS 地区工作。HTTP 验证只能通过 “ CloudFront 分发租户” 功能进行。 1. 打开 ACM 控制台，网址为。[https://console.aws.amazon.com/acm/](https://console.aws.amazon.com/acm/) 1. 在证书列表中，请选择要配置的状态为 **Pending validation**（等待验证）的证书的 **Certificate ID**（证书 ID）。此时将打开证书的详细信息页面。 1. 在**域**部分中，您可以看到证书请求中每个域的**重定向自**和**重定向至**值。 1. 对于每个域，设置从**重定向自** URL 到**重定向至** URL 的 HTTP 重定向。你可以通过你的 CloudFront 分发配置来做到这一点。 1. 将您的 CloudFront 分配配置为将请求从 “重**定**向自” URL 重定向到 URL **重定向**。设置此重定向的方法取决于您的 CloudFront 配置。 1. 设置重定向后，ACM 会自动尝试验证您的域所有权。这一过程耗时最多 30 分钟。 如果 ACM 在为您生成重定向值后的 72 小时内无法验证域名，ACM 会将证书状态更改为 **Validation timed out（验证超时）**。导致此结果的最可能原因是您未成功设置 HTTP 重定向。要解决此问题，您必须在查看重定向说明后请求新的证书。 **重要** 为避免验证问题，请确保**重定向自**位置的内容与**重定向至**位置的内容相匹配。如果遇到问题，请参阅[解决 HTTP 验证问题](troubleshooting-HTTP-validation.md)。 **注意** 与 DNS 验证不同的是，您无法以编程方式请求 ACM 自动创建您的 HTTP 重定向。您必须通过 CloudFront 分发设置配置这些重定向。 有关 HTTP 验证的工作方式的更多信息，请参阅 [ACM 的 HTTP 重定向的工作原理](#http-redirects-overview)。