通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Front Door 中的域

  • 项目

域表示 Azure Front Door 用于接收应用程序流量的自定义域名。 Azure Front Door 支持添加三种类型的域名：

  • 子域是最常见的自定义域名类型。 子域示例如下：myapplication.contoso.com。
  • Apex 域不包含子域。 Apex 域示例如下：contoso.com。 有关将 apex 域与 Azure Front Door 配合使用的详细信息，请参阅 Apex 域。
  • 通配符域允许接收任何子域的流量。 通配符域示例如下：*.contoso.com。 有关将通配符域与 Azure Front Door 配合使用的详细信息，请参阅通配符域。

域将添加到 Azure Front Door 配置文件。 如果在每个路由中使用不同的路径，则可以在终结点内的多个路由中使用域。

若要了解如何将自定义域添加到 Azure Front Door 配置文件，请参阅使用 Azure 门户在 Azure Front Door 上配置自定义域。

DNS 配置

将域添加到 Azure Front Door 配置文件时，需要在 DNS 服务器中配置以下两个记录：

  • DNS TXT 记录，它是验证域名所有权所必需的。 有关 DNS TXT 记录的详细信息，请参阅域验证。
  • DNS CNAME 记录，它用于控制流向 Azure Front Door 的 Internet 流量。

提示

在进行任何 DNS 更改之前，可以将域名添加到 Azure Front Door 配置文件。 如果需要一起设置 Azure Front Door 配置，或者有单独的团队负责更改 DNS 记录，则此方法非常有用。

在添加 CNAME 记录以控制流量流之前，还可以添加 DNS TXT 记录来验证域所有权。 如果某个应用程序已投入生产，则此方法有助于避免遇到迁移停机。

域验证

必须对添加到 Azure Front Door 的所有域进行验证。 验证有助于防止意外的错误配置，也有助于保护其他人免受域欺骗。 在某些情况下，域可以由另一个 Azure 服务进行预验证。 否则，需要遵循 Azure Front Door 域验证过程来证明你对域名的所有权。

  • Azure 预验证域是指已由另一个受支持的 Azure 服务验证的域。 如果要在另一个 Azure 服务中加入并验证域，并在随后配置 Azure Front Door，可以使用预验证的域。 使用此类型的域时，无需通过 Azure Front Door 验证域。

    注意

    Azure Front Door 目前仅接受已使用 Azure Static Web Apps 配置的预验证域。

  • 非 Azure 验证的域是指未经受支持的 Azure 服务验证的域。 此域类型可以使用任何 DNS 服务（包括 Azure DNS）进行托管，并且需要使用 Azure Front Door 进行域所有权验证。

TXT 记录验证

若要验证域，需要创建 DNS TXT 记录。 TXT 记录的名称必须采用 _dnsauth.{subdomain} 格式。 开始将域添加到 Azure Front Door 时，Azure Front Door 将为 TXT 记录提供唯一值。

例如，假设你想要将自定义子域 myapplication.contoso.com 与 Azure Front Door 配合使用。 首先，应将域添加到 Azure Front Door 配置文件，并记下需要使用的 TXT 记录值。 然后，应使用以下属性配置 DNS 记录：

属性 值
记录名称 _dnsauth.myapplication
记录值 使用 Azure Front Door 提供的值
生存时间 (TTL) 1 小时

成功验证域后，可以从 DNS 服务器安全地删除 TXT 记录。

有关为自定义域添加 DNS TXT 记录的详细信息，请参阅使用 Azure 门户在 Azure Front Door 上配置自定义域。

域验证状态

下表列出了域可能显示的验证状态。

域验证状态 说明和操作
正在提交 正在创建自定义域。

等待域资源准备就绪。
挂起的 已生成 DNS TXT 记录值，并且 Azure Front Door 已准备好添加 DNS TXT 记录。

请将 DNS TXT 记录添加到 DNS 提供程序，并等待验证完成。 如果状态仍为“挂起”（即使在 TXT 记录已使用 DNS 提供商更新后也是如此），请选择“重新生成”以刷新 TXT 记录，然后再次将 TXT 记录添加到 DNS 提供程序。
重新验证挂起 托管证书距离到期不足 45 天。

如果有已指向 Azure Front Door 终结点的 CNAME 记录，则不需要执行任何操作来续订证书。 如果自定义域指向另一条 CNAME 记录，请选择“等待重新验证”状态，然后在“验证自定义域”页上选择“重新生成”。 最后，选择“添加”（如果使用 Azure DNS），或者使用自己的 DNS 提供程序的 DNS 管理手动添加 TXT 记录。
正在刷新验证令牌 选择“重新生成”按钮后，域将短暂进入“正在刷新验证令牌”阶段。 发出新的 TXT 记录值后，状态将变为“挂起”。
不需要执行任何操作。
已批准 已成功验证该域，并且 Azure Front Door 可以接受使用此域的流量。

不需要执行任何操作。
已拒绝 证书提供程序/颁发机构拒绝了托管证书的颁发。 例如，域名可能无效。

请选择“被拒绝”链接，然后在“验证自定义域”页上选择“重新生成”，如此表下方的屏幕截图中所示。 然后选择“添加”，以在 DNS 提供程序中添加 TXT 记录。
超时 TXT 记录未在 7 天内添加到你的 DNS 提供程序，或者添加了无效的 DNS TXT 记录。

选择“超时”链接，然后在“验证自定义域”页上选择“重新生成”。 然后选择“添加”，以将新的 TXT 记录添加到 DNS 提供程序。 确保使用更新的值。
内部错误 出现未知错误。

通过选择“刷新”或“重新生成”按钮重试验证。 如果仍然遇到问题，请向 Azure 支持提交支持请求。

注意

  • TXT 记录的默认 TTL 为 1 小时。 需要重新生成 TXT 记录以重新验证时，请注意以前的 TXT 记录的 TTL。 如果未过期，验证将失败，直到以前的 TXT 记录过期。
  • 如果“重新生成”按钮不起作用，请删除并重新创建域。
  • 如果域状态未按预期方式反映，请选择“刷新”按钮。

自定义域的 HTTPS

通过在自定义域上使用 HTTPS 协议，可以确保敏感数据在通过 Internet 发送时可以通过 TLS/SSL 加密安全地进行传输。 当客户端（如 Web 浏览器）使用 HTTPS 连接到网站时，该客户端会验证网站的安全证书，并确保它由合法的证书颁发机构颁发。 此过程提供安全性并保护 Web 应用程序免受攻击。

Azure Front Door 支持将 HTTPS 与你自己的域配合使用，并从源服务器卸载传输层安全性 (TLS) 证书管理。 使用自定义域时，可以使用 Azure 托管的 TLS 证书（推荐），也可以购买并使用自己的 TLS 证书。

有关 Azure Front Door 如何与 TLS 配合使用的详细信息，请参阅将端到端 TLS 与 Azure Front Door 配合使用。

Azure Front Door 托管的 TLS 证书

Azure Front Door 可以自动管理子域和 apex 域的 TLS 证书。 使用托管证书时，无需创建密钥或证书签名请求，也无需上传、存储或安装证书。 此外，Azure Front Door 可以自动轮换（续订）托管证书，而无需任何人工干预。 此流程可避免因未能及时续订 TLS 证书而导致的停机。

生成、颁发和安装托管 TLS 证书的过程可能需要几分钟到一个小时才能完成，有时可能需要更长的时间。

注意

如果域 CNAME 记录直接指向 Front Door 终结点或间接指向流量管理器终结点，Azure Front Door（标准和高级）托管证书会自动轮换。 否则，需要重新验证域所有权才能轮换证书。

域类型

下表汇总了使用不同类型的域时托管 TLS 证书提供的功能：

注意事项 子域 Apex 域 通配符域
可用的托管 TLS 证书 是 是 否
托管 TLS 证书会自动轮换 是 请参阅下文 否

将 Azure Front Door 托管的 TLS 证书与 apex 域配合使用时，自动证书轮换可能会要求你重新验证域所有权。 有关详细信息，请参阅 Azure Front Door 中的 Apex 域。

托管证书颁发

Azure Front Door 的证书由合作伙伴证书颁发机构 DigiCert 颁发。 对于某些域，必须通过创建值为 0 issue digicert.com 的 CAA 域记录显式允许 DigiCert 作为证书颁发者。

Azure 代表你完全管理证书，因此可以随时更改托管证书的任何方面（包括根证书颁发者）。 这些更改不受你控制。 务必避免对托管证书的任何方面具有硬依赖，例如检查证书指纹，或者固定到托管证书或证书层次结构的任何部分。 如果需要固定证书，你应使用客户管理的 TLS 证书，如下一节所述。

客户管理的 TLS 证书

有时，可能需要提供自己的 TLS 证书。 提供你自己的证书的常见场景包括：

  • 组织要求使用由特定证书颁发机构颁发的证书。
  • 你希望 Azure Key Vault 使用合作伙伴证书颁发机构来颁发证书。
  • 需要使用客户端应用程序可识别的 TLS 证书。
  • 需要在多个系统上使用相同的 TLS 证书。
  • 使用通配符域。 Azure Front Door 无法为通配符域提供托管证书。

注意

  • 从 2023 年 9 月开始，Azure Front Door 支持使用自带证书 (BYOC) 来验证域所有权。 如果证书的证书名称 (CN) 或使用者可选名称 (SAN) 与自定义域匹配，Front Door 会批准域所有权。 如果选择 Azure 托管证书，域验证将使用 DNS TXT 记录。
  • 对于在基于 BYOC 的验证之前创建的自定义域，并且域验证状态不是“已批准”，则你需要选择“验证状态”触发域所有权验证的自动审批，然后单击门户中的“重新验证”按钮。 如果使用命令行工具，可通过向域 API 发送空的 PATCH 请求来触发域验证。

证书要求

若要将证书用于 Azure Front Door，必须满足以下要求：

  • 证书链完整：创建 TLS/SSL 证书时，必须使用 Microsoft 受信任 CA 列表中允许的证书颁发机构 (CA) 创建完整的证书链。 如果使用不允许的 CA，则会拒绝你的请求。 根 CA 必须是 Microsoft 受信任的 CA 列表的一部分。 如果提供的是没有完整链的证书，则不能保证涉及该证书的请求实现预期效果。
  • 公用名称：证书的公用名称 (CN) 必须与 Azure Front Door 中配置的域匹配。
  • 算法：Azure Front Door 不支持带椭圆曲线 (EC) 加密算法的证书。
  • 文件（内容）类型：证书必须从使用 application/x-pkcs12 内容类型的 PFX 文件上传到密钥保管库。

将证书导入 Azure Key Vault

必须先将自定义 TLS 证书导入到 Azure 密钥保管库，然后才能将其与 Azure Front Door 配合使用。 若要了解如何将证书导入密钥保管库，请参阅教程：在 Azure Key Vault 中导入证书。

密钥保管库必须与 Azure Front Door 配置文件位于同一 Azure 订阅中。

警告

Azure Front Door 仅支持 Front Door 配置文件所在的同一订阅中的密钥保管库。 在与 Azure Front Door 配置文件不同的订阅下选择密钥保管库将导致失败。

证书必须作为证书对象而不是机密上传。

向 Azure Front Door 授予访问权限

Azure Front Door 需要访问密钥保管库才能读取证书。 需要配置密钥保管库的网络防火墙和保管库的访问控制。

如果密钥保管库启用了网络访问限制，则必须将密钥保管库配置为允许受信任的 Microsoft 服务绕过防火墙。

可通过两种方式在密钥保管库上配置访问控制：

  • Azure Front Door 可以使用托管标识来访问密钥保管库。 当密钥保管库使用 Microsoft Entra 身份验证时，可以使用此方法。 有关详细信息，请参阅将托管标识用于 Azure Front Door 标准版/高级版。
  • 或者，可以向 Azure Front Door 的服务主体授予对密钥保管库的访问权限。 使用保管库访问策略时，可以使用此方法。

将自定义证书添加到 Azure Front Door

将证书导入到密钥保管库后，创建 Azure Front Door 机密资源，该资源是对添加到密钥保管库的证书的引用。

然后，配置你的域以将 Azure Front Door 机密用于其 TLS 证书。

有关这些步骤的指导演练，请参阅使用 Azure 门户在 Azure Front Door 自定义域上配置 HTTPS。

在证书类型之间切换

可以在使用 Azure Front Door 托管证书和用户管理的证书之间更改域。

  • 切换证书类型后，可能需要花费一个小时来部署新证书。
  • 如果域状态为“已批准”，则在用户管理的证书与托管证书之间切换证书类型不会造成任何停机时间。
  • 切换到托管证书时，Azure Front Door 将继续使用之前的证书，直到重新验证域所有权，并且域状态变为“已批准”。
  • 如果从 BYOC 切换到托管证书，需要重新验证域。 如果从托管证书切换到 BYOC，则无需重新验证域。

证书续订

续订 Azure Front Door 托管证书

对于大多数自定义域，Azure Front Door 会在托管证书临近到期时自动续订（轮换）它们，你无需执行任何操作。

但是，在以下情况下，Azure Front Door 不会自动轮换证书：

  • 自定义域的 CNAME 记录指向 Azure Front Door 终结点的域以外的 DNS 记录。
  • 自定义域通过链指向 Azure Front Door 终结点。 例如，如果 DNS 记录指向 Azure 流量管理器，后者又解析为 Azure Front Door，则 CNAME 链为 contoso.com CNAME in contoso.trafficmanager.net CNAME in contoso.z01.azurefd.net。 Azure Front Door 无法验证整个链。
  • 自定义域使用 A 记录。 建议始终使用 CNAME 记录来指向 Azure Front Door。
  • 自定义域是 apex 域，并使用 CNAME 平展。

如果上述场景之一适用于你的自定义域，则在托管证书到期前 45 天，域验证状态将变为“等待重新验证”。 “等待重新验证”状态指示需要创建新的 DNS TXT 记录来重新验证域所有权。

注意

DNS TXT 记录将在 7 天后过期。 如果之前已将域验证 TXT 记录添加到 DNS 服务器，则你需要将其替换为新的 TXT 记录。 请确保使用新值，否则域验证过程将失败。

如果无法验证域，则域验证状态将变为“已拒绝”。 此状态表示证书颁发机构已拒绝重新颁发托管证书的请求。

有关域验证状态的详细信息，请参阅域验证状态。

为由其他 Azure 服务预验证的域续订 Azure 托管证书

Azure 托管证书由验证域的 Azure 服务自动轮换。

续订客户管理的 TLS 证书

当更新密钥保管库中的证书时，Azure Front Door 可以自动检测并使用更新的证书。 若要使此功能正常工作，请在 Azure Front Door 中配置证书时将机密版本设置为“最新”。

如果已选择特定版本的证书，则必须在更新证书时手动重新选择新版本。

自动部署新版本的证书/机密最多需要 72 小时。

如果要将机密版本从“最新”更改为某个指定版本或者反向操作，请添加一个新证书。

安全策略

可以使用 Azure Front Door 的 Web 应用程序防火墙 (WAF) 来扫描对应用程序的请求以查找威胁，并强制实施其他安全要求。

若要将 WAF 与自定义域配合使用，请使用 Azure Front Door 安全策略资源。 安全策略将域与 WAF 策略相关联。 可以选择创建多个安全策略，以便能够对不同的域使用不同的 WAF 策略。

后续步骤