共用方式為

Azure Front Door 中的域

适用于: ✔️ Front Door 标准 ✔️ Front Door Premium

自定义域是 Azure Front Door 用来接收应用程序流量的域名。 Azure Front Door 支持添加三种类型的域名:

  • 子域 是最常见的自定义域名类型。 子域示例如下:myapplication.contoso.com
  • Apex 域 不包含子域。 Apex 域示例如下:contoso.com。 有关将顶点域与 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 流量。

Tip

在进行任何 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 验证域。

    Note

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

  • 非 Azure 验证的域是指未经受支持的 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 记录:

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

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

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

域验证状态

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

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

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

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

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

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

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

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

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

Note

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

自定义域的 HTTPS

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

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

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

客户管理的 TLS 证书

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

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

Note

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

证书要求

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

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

将证书导入 Azure Key Vault

必须先将自定义 TLS 证书导入 Azure Key Vault,然后才能将其与 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 的 Web 应用程序防火墙 (WAF) 来扫描对应用程序的请求以查找威胁,并强制实施其他安全要求。

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

后续步骤