相互身份验证或客户端身份验证允许应用程序网关对发送请求的客户端进行身份验证。 通常，只有客户端对应用程序网关进行身份验证；相互身份验证允许客户端和应用程序网关对彼此进行身份验证。
备注
建议将 TLS 1.2 与相互身份验证配合使用，因为将来会强制要求使用 TLS 1.2。
相互身份验证
应用程序网关支持基于证书的相互身份验证，可以在其中将受信任的客户端 CA 证书上传到应用程序网关，网关使用该证书对向网关发送请求的客户端进行身份验证。 随着各行业中 IoT 用例的增加和安全要求的提高，相互身份验证提供了一种用于管理和控制哪些客户端可与应用程序网关通信的方式。
应用程序网关提供以下两个选项来验证客户端证书：
双向 TLS 透传模式
在相互 TLS 传递模式下，应用程序网关在 TLS 握手期间请求客户端证书，但如果证书缺失或无效，则不会终止连接。 无论证书的存在或有效性如何，与后端的连接都会继续进行。 如果提供了证书，应用程序网关可以根据需要将其转发到后端。 后端服务负责验证客户端证书。 如果要配置证书转发，请参阅服务器变量。 当 CA 证书处于直通模式时，无需上传任何 CA 证书。 要设置直通，请按照使用 ARM 模板配置应用程序网关以实现双向身份验证中的步骤操作。
备注
目前，仅使用 API 版本 2025-03-01 的 Azure 资源管理器部署才支持此功能。
双向 TLS 严格模式
在相互 TLS 严格模式下，应用程序网关通过在 TLS 握手期间要求有效的客户端证书来强制执行客户端证书身份验证。 若要启用此功能，必须上传包含根 CA 和（可选）中间 CA 的受信任客户端 CA 证书作为 SSL 配置文件的一部分。 然后，此 SSL 配置文件与侦听器相关联，以强制实施相互身份验证。
配置双向 TLS 严格模式的详细信息
若要配置相互身份验证严格模式，需要将受信任的客户端 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 使用。
TLS 双向严格模式下支持的身份验证证书
应用程序网关支持由公共和私有证书颁发机构颁发的证书。
- 从知名证书颁发机构（CA）颁发的证书：中间证书和根证书通常存储在受信任的证书库中，可以在设备上几乎无需额外配置地启用受信任的连接。
- 由组织建立的证书颁发机构颁发的 CA 证书：这些证书通常是通过你的组织私下颁发的，不受其他实体的信任。 中间证书和根证书必须导入到受信任的证书存储中，客户端才能建立链式信任。
备注
从公认的证书书颁发机构颁发客户端证书时，请考虑与证书颁发机构合作，查看是否可以为你的组织颁发中间证书，以防止意外的跨组织客户端证书身份验证。
相互 TLS 严格模式的附加客户端身份验证校验
验证客户端证书 DN
你可以选择验证客户端证书的直接颁发者，并仅允许应用程序网关信任该颁发者。 此选项默认处于关闭状态，但可以通过门户、PowerShell 或 Azure CLI 启用此选项。
如果选择启用应用程序网关来验证客户端证书的直接颁发者，请参阅下文了解如何确定要从上传的证书中提取的客户端证书颁发者 DN。
-
场景 1：证书链包含：根证书 - 中间证书 - 叶证书
- 中间证书的使用者名称是将由应用程序网关提取为客户端证书颁发者 DN 并用作验证依据的内容。
-
场景 2：证书链包含：根证书 - 中间证书 1 - 中间证书 2 - 叶证书
- 中间 2 证书的 主题名是提取为客户端证书颁发者 DN 的内容，将对其进行验证。
-
场景 3：证书链包含：根证书 - 叶证书
- 根证书的 使用者名称被提取，并作为客户端证书的颁发者 DN。
-
场景 4：同一文件中包含多个长度相同的证书链。 链 1 包含：根证书 - 中间证书 1 - 叶证书。 链 2 包含：根证书 - 中间证书 2 - 叶证书。
- Intermediate1证书的主题名称被提取为客户端证书发行者的DN。
-
场景 5：同一文件中包含多个具有不同长度的证书链。 链 1 包含：根证书 - 中间证书 1 - 叶证书。 链 2 包含：根证书 - 中间证书 2 - 中间证书 3 - 叶证书。
- Intermediate3 证书的 主体名称被提取为客户端证书的发行者 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 响应中定义的 nextUpdate 时间戳来验证 OCSP 检查过程。 如果 OCSP 缓存尚未从以前的请求中填充，则第一个响应可能会失败。 重试客户端后，应会在缓存中找到响应，并且将按预期处理请求。
说明
- 不支持通过 CRL 进行吊销检查
- API 版本 2022-05-01 中引入了客户端吊销检查
后续步骤
了解相互身份验证后，请转到在 PowerShell 中为应用程序网关配置相互身份验证，以创建一个使用相互身份验证的应用程序网关。