应用程序网关中的相互身份验证概述

相互身份验证或客户端身份验证允许应用程序网关对发送请求的客户端进行身份验证。 通常,只有客户端对应用程序网关进行身份验证;相互身份验证允许客户端和应用程序网关对彼此进行身份验证。

备注

建议将 TLS 1.2 与相互身份验证配合使用,因为将来会强制要求使用 TLS 1.2。

相互身份验证

应用程序网关支持基于证书的相互身份验证,在其中可以将受信任的客户端 CA 证书上传到应用程序网关,网关将使用该证书对向网关发送请求的客户端进行身份验证。 随着各行业中 IoT 用例的增加和安全要求的提高,相互身份验证提供了一种用于管理和控制哪些客户端可与应用程序网关通信的方式。

若要配置相互身份验证,必须将受信任的客户端 CA 证书作为 SSL 配置文件的客户端身份验证部分上传。 然后,需要将 SSL 配置文件关联到侦听器,以完成相互身份验证的配置。 上传的客户端证书中必须始终有一个根 CA 证书。 你也可以上传证书链,但该链除了包含所需数量的中间 CA 证书以外,还必须包含一个根 CA 证书。 每个上载文件的最大大小必须小于或等于 25 KB.

例如,如果你的客户端证书包含一个根 CA 证书、多个中间 CA 证书和一个叶证书,请确保在一个文件中将根 CA 证书和所有中间 CA 证书上传到应用程序网关。 要详细了解如何提取受信任的客户端 CA 证书,请参阅如何提取受信任的客户端 CA 证书

如果要上传包含根 CA 证书和中间 CA 证书的证书链,必须将该证书链作为 PEM 或 CER 文件上传到网关。

重要

使用相互身份验证时,请确保将整个受信任客户端 CA 证书链上传到应用程序网关。

每个 SSL 配置文件最多可支持 100 个受信任的客户端 CA 证书链。 单一应用程序网关总共可以支持 200 个受信任的客户端 CA 证书链。

注意

  • 只能在 Standard_v2 和 WAF_v2 SKU 上使用相互身份验证。
  • TLS 协议侦听器(预览版)的相互身份验证配置目前可通过 REST API、PowerShell 和 CLI 使用。 Azure 门户支持即将推出。

相互身份验证支持的证书

应用程序网关支持由公共和私有证书颁发机构颁发的证书。

  • 由知名证书颁发机构颁发的 CA 证书:中间证书和根证书通常可在受信任的证书存储中找到,并且只需在设备上进行很少或完全无需进行任何额外配置即可实现受信任的连接。
  • 由组织建立的证书颁发机构颁发的 CA 证书:这些证书通常是通过你的组织私下颁发的,不受其他实体的信任。 中间证书和根证书必须导入到受信任的证书存储中,客户端才能建立链式信任。

注意

从公认的证书书颁发机构颁发客户端证书时,请考虑与证书颁发机构合作,查看是否可以为你的组织颁发中间证书,以防止意外的跨组织客户端证书身份验证。

其他有关客户端身份验证的验证

验证客户端证书 DN

你可以选择验证客户端证书的直接颁发者,并仅允许应用程序网关信任该颁发者。 此选项默认处于关闭状态,但可以通过门户、PowerShell 或 Azure CLI 启用此选项。

如果选择启用应用程序网关来验证客户端证书的直接颁发者,请参阅下文了解如何确定要从上传的证书中提取的客户端证书颁发者 DN。

  • 场景 1:证书链包含:根证书 - 中间证书 - 叶证书
    • 中间证书的使用者名称是将由应用程序网关提取为客户端证书颁发者 DN 并用作验证依据的内容。
  • 场景 2:证书链包含:根证书 - 中间证书 1 - 中间证书 2 - 叶证书
    • 中间证书 2 的使用者名称是将提取为客户端证书颁发者 DN 并用作验证依据的内容。
  • 场景 3:证书链包含:根证书 - 叶证书
    • 根证书的使用者名称将作为客户端证书颁发者 DN 提取和使用。
  • 场景 4:同一文件中包含多个长度相同的证书链。 链 1 包含:根证书 - 中间证书 1 - 叶证书。 链 2 包含:根证书 - 中间证书 2 - 叶证书。
    • 将提取中间证书 1 的使用者名称作为客户端证书颁发者 DN。
  • 场景 5:同一文件中包含多个具有不同长度的证书链。 链 1 包含:根证书 - 中间证书 1 - 叶证书。 链 2 包含:根证书 - 中间证书 2 - 中间证书 3 - 叶证书。
    • 将提取中间证书 3 的使用者名称作为客户端证书颁发者 DN。

重要

我们建议每个文件仅上传一个证书链。 如果你要启用验证客户端证书 DN 的功能,这一点特别重要。 如果在一个文件中上传多个证书链,最终会出现场景 4 或 5 中所述的情况,并且在提供的客户端证书与应用程序网关从链中提取的客户端证书颁发者 DN 不匹配的情况下,将来可能会出现问题。

要详细了解如何提取受信任的客户端 CA 证书链,请参阅如何提取受信任的客户端 CA 证书链

服务器变量

使用相互 TLS 身份验证时,可以使用其他服务器变量将有关客户端证书的信息传递到应用程序网关后面的后端服务器。 有关可用服务器变量及其用法的详细信息,请查看服务器变量

证书吊销

当客户端发起与配置了相互 TLS 身份验证的应用程序网关的连接时,不仅可以验证证书链和颁发者的可分辨名称,还可以使用 OCSP(联机证书状态协议)检查客户端证书的吊销状态。 在验证期间,将通过在其颁发机构信息访问 (AIA) 扩展中定义的 OCSP 响应程序查找客户端提供的证书。 如果客户端证书被吊销,应用程序网关将使用 HTTP 400 状态代码和原因响应客户端。 如果证书有效,则请求将继续由应用程序网关处理,并转发到定义的后端池。

可以通过 REST API、ARM、Bicep、CLI 或 PowerShell 启用客户端证书吊销。

若要通过 Azure PowerShell 在现有应用程序网关上配置客户端吊销检查,可以参考以下命令:

# Get Application Gateway configuration
$AppGw = Get-AzApplicationGateway -Name "ApplicationGateway01" -ResourceGroupName "ResourceGroup01"

# Create new SSL Profile
$profile  = Get-AzApplicationGatewaySslProfile -Name "SslProfile01" -ApplicationGateway $AppGw

# Verify Client Cert Issuer DN and enable Client Revocation Check
Set-AzApplicationGatewayClientAuthConfiguration -SslProfile $profile -VerifyClientCertIssuerDN -VerifyClientRevocation OCSP

# Update Application Gateway
Set-AzApplicationGateway -ApplicationGateway $AppGw

下面提供了一个列表,其中列出应用程序网关上的客户端身份验证配置的所有 Azure PowerShell 参考:

为了验证是否已针对客户端请求评估 OCSP 吊销状态,访问日志将包含一个名为“sslClientVerify”的属性,该属性具有 OCSP 响应的状态。

OCSP 响应程序高度可用,并且应用程序网关与响应程序之间可建立网络连接,这一点至关重要。 如果应用程序网关无法解析定义的响应程序的完全限定的域名 (FQDN),或者阻止到/来自响应程序的网络连接,那么证书吊销状态将失败,并且应用程序网关将向请求客户端返回 400 HTTP 响应。

注意:OCSP 检查基于上一 OCSP 响应定义的 nextUpdate 时间,通过本地缓存进行验证。 如果尚未从上一个请求填充 OCSP 缓存,则第一个响应可能会失败。 重试客户端后,应会在缓存中找到响应,并且将按预期处理请求。

说明

  • 不支持通过 CRL 进行吊销检查
  • API 版本 2022-05-01 中引入了客户端吊销检查

后续步骤

了解相互身份验证后,请转到在 PowerShell 中为应用程序网关配置相互身份验证,以创建一个使用相互身份验证的应用程序网关。