亚马逊AWS官方博客
适用于应用程序负载均衡器的 mTLS 简介
mTLS 概念
双向传输层安全性协议（mTLS）扩展了用于保护网络通信的 TLS 协议。TLS 通常用于通过互联网建立安全连接，确保身份验证、数据机密性和完整性。但是，在传统 TLS 中，身份验证是单方面的，服务器向客户端验证自己的身份，而不验证客户端的身份。
相比之下，mTLS 通过要求服务器和客户端相互进行身份验证来添加额外的安全层，因此被称为“相互”或“双向”TLS。与 mTLS 相关的一些概念：
- 证书颁发机构 (CA)：向企业提供 TLS 证书的组织/实体。在颁发 TLS 证书之前，CA 会验证域名和所有者详细信息。
- TLS 证书：一种数字对象，允许系统（如 Web 客户端）验证另一个系统（如 Web 服务器）的身份。TLS 证书中的详细信息允许客户端与服务器建立加密连接。
- 服务器证书：证明服务器身份的 TLS 证书。
- 客户端证书：证明客户端身份的 TLS 证书。
- 证书信任链：TLS 证书的有序列表。链以左边的证书（或客户端/服务器的 TLS 证书）开始，以根证书结束。叶证书和根证书之间的任何证书都称为中间证书。链中的每份证书都由下一个证书所标识的组织/实体签署。如图 1 所示。
 |
图 1：证书信任链
- TLS 握手：允许客户端和服务器使用其 TLS 证书相互进行身份验证、商定加密标准以及为传输日期创建安全通道的过程。有关更多详细信息，请参阅 TLS 文档。在 TLS 握手期间，客户端与服务器共享其 TLS 证书。这使服务器可以对客户端进行身份验证。
- 证书吊销列表 (CRL)：不应信任的列入黑名单的证书列表。
mTLS 流程通常用于保护智能设备、API 和微服务之间的通信，以及任何双方都必须对彼此身份建立信任的情况，例如满足监管要求。它还用于虚拟专用网络（VPN）和保护组织内部通信。
要实施 mTLS，服务器和客户端都必须拥有可信 CA 颁发的数字证书。这些证书可以由相同或不同的 CA 生成，用于在握手过程中证明各方的真实性。
将 mTLS 客户端身份验证与应用程序负载均衡器结合使用
当客户端的证书链在一定深度和大小范围内时，应用程序负载均衡器支持 mTLS。查看应用程序负载均衡器配额文档，了解当前支持的最大大小和深度。您可以分别使用应用程序负载均衡器的 ClientCertExceedsDepthLimit 和 ClientCertExceedsSizeLimit Amazon CloudWatch 指标来跟踪任何违反这些限制的请求。
应用程序负载均衡器支持 mTLS 的两种操作模式：mTLS 验证模式和 mTLS 直通模式。
mTLS 验证模式
要在应用程序负载均衡器中使用 mTLS 验证模式，必须创建信任库。信任库有一个 CA 证书捆绑包，用于验证客户端证书。您可以自带证书，也可以使用 AWS Certificate Manager (ACM) 生成证书。您可以将 AWS 托管的 CA 用于应用程序负载均衡器的 mTLS 验证模式。 AWS Private Certificate Authority 是一项高度可用的托管 CA 服务，可帮助组织使用私有证书保护应用程序和设备。要了解更多信息，请参阅 ACM 有关颁发和管理证书的文档。
要指定哪些客户端证书不可信任，请将一个或多个证书吊销列表 (CRL) 与信任库关联起来。您将吊销列表上传到 S3 存储桶中，然后在信任库下指定存储桶。ALB 从 S3 导入 CRL，任何 CRL 检查都由 ALB 执行，无需每次都从 S3 获取 CRL。因此，ALB 在根据 CRL 对客户端进行身份验证时不会添加任何延迟。有关 CRL 配置的更多详细信息，请查看我们文档中的在应用程序负载均衡器中使用 TLS 进行双向身份验证页面。
在此模式下，应用程序负载均衡器将使用信任库验证客户端证书。这样可以确保只有通过有效证书进行身份验证的客户端才能与后端目标通信。ALB 会阻止来自未经身份验证的用户的请求。这使您可以将 mTLS 身份验证所需的计算密集型处理转移到应用程序负载均衡器，并使用后端目标的处理资源提供应用程序的服务。图 2 显示了验证模式的架构。
 |
图 2：在 mTLS 验证模式下配置的应用程序负载均衡器
在 ALB 验证模式下，mTLS 的阶段包括：
[1] 将 CA 证书捆绑包上传到 Amazon S3 中，也可以选择上传 CRL。
[2] 创建信任库，并提供 CA 证书捆绑包的 Amazon S3 路径。另外，还提供 CRL 的 Amazon S3 路径。
[3] 客户端启动与 ALB 的 TLS 会话。在 TLS 握手期间，客户端出示其 TLS 证书。
[4] TLS 会话在 ALB 终止。在 TLS 握手期间，ALB 出示服务器端证书并接收客户端的证书。
[5] ALB 查询信任库并验证证书。如果客户端证书未由可信 CA 签署，证书列在证书吊销列表 (CRL) 中，或者客户端证书已过期，则客户端身份验证将失败。有关在应用程序负载均衡器的 mTLS 验证模式下客户端身份验证可能失败的场景的完整列表，请参阅我们文档中的在应用程序负载均衡器中使用 TLS 进行双向身份验证页面。如果客户端身份验证失败，应用程序负载均衡器会拒绝 TLS 连接。对于过期的证书，您可以选择将 ALB 配置为允许此类连接。
[6] 客户端和 ALB 之间成功建立 TLS 会话
[7] ALB 为后端目标创建单独的会话。
由于应用程序负载均衡器会终止 TLS 会话，您可以使用 ALB 的任何路由算法对流向后端目标的流量进行负载均衡。例如，您可以使用加权轮询规则来创建 Web 应用程序的蓝绿部署。
除了执行客户端身份验证之外，应用程序负载均衡器还向后端目标发送以下证书元数据：
X-Amzn-Mtls-Clientcert-Serial-Number – 叶证书或客户端证书序列号的十六进制表示形式，例如 0ABC1234
X-Amzn-Mtls-Clientcert-Issuer – 使用带有 XN_FLAG_RFC2253 标志的 X509_NAME_print_ex 打印的颁发者可分辨名称 (DN)
X-Amzn-Mtls-Clientcert-Subject – 使用带有 XN_FLAG_RFC2253 标志的 X509_NAME_print_ex 打印的主题 DN
X-Amzn-Mtls-Clientcert-Validity – ISO8601 格式的 notBefore 和 notAfter 日期，例如，NotBefore=2023-09-21T01:50:17Z；NotAfter=2024-09-20T01:50:17Z
X-Amzn-Mtls-Clientcert-Leaf – URL 编码 PEM 格式的叶证书
此信息允许您在后端目标上根据这些元数据字段实现逻辑。例如，您可以解析 X-Amzn-Mtls-Clientcert-Leaf 字段以获取证书的到期日期，并在证书接近到期日期时向客户端发送自定义消息。
mTLS 直通模式
在此模式下，ALB 在名为 AMZN-MTLS-CLIENT-CERT 的 HTTP 标头中将整个证书链转发到后端目标以进行客户端身份验证。ALB 以 URL 编码的 PEM 格式插入整个证书链（包括叶证书），并使用 +、= 和 / 作为安全字符。下面是 AMZN-MTLS-CLIENT-CERT 标头的示例：
X-Amzn-Mtls-Clientcert:
后端目标必须能够解析此 HTTP 标头、提取证书并执行客户端身份验证。如果您想保留对客户端身份验证过程的控制，请使用此模式。图 3 显示了此架构。
 |
图 3：在 mTLS 直通模式下配置的应用程序负载均衡器
在 ALB 直通模式下，mTLS 的阶段包括：
[1] 客户端启动与 ALB 的 TLS 会话。在 TLS 握手期间，客户端出示其 TLS 证书。
[2] TLS 会话在 ALB 终止。在 TLS 握手期间，ALB 出示服务器端证书并接收客户端的证书。
[3] ALB 与后端目标创建新会话。根据用户配置，此会话可以是 HTTP 或 HTTPS。ALB 将整个证书链包含在名为 AMZN-MTLS-CLIENT-CERT 的 HTTP 标头中。
[4] 后端目标接收客户端证书，并且必须实现从 AMZN-MTLS-CLIENT-CERT HTTP 标头解析客户端证书链的逻辑。目标还必须实现执行客户端身份验证的逻辑。
如果启用 mTLS 直通模式时没有客户端证书，则应用程序负载均衡器不会添加任何额外的 HTTP 标头。后端目标必须实现无需客户端证书即可处理传入请求的逻辑。
如果后端目标上的客户端身份验证失败，则目标必须处理向应用程序负载均衡器发回 HTTP 错误代码的操作。ALB 将此错误代码转发回客户端。
对于 HTTPS 侦听器，后端目标根据证书对客户端进行身份验证，应用程序负载均衡器终止客户端之间的 TLS 连接，并与后端目标打开另一个 TLS 会话。ALB 和后端目标之间的 TLS 会话是使用您在目标上安装的证书创建的。
由于 ALB 会终止 TLS 会话，您可以使用 ALB 的任何路由算法对流向后端目标的流量进行负载均衡。
某些智能设备可能会长时间处于离线状态，例如，智能汽车暂时断开互联网连接。在这些情况下，您需要确保后端目标实现使用过期的 TLS 证书的逻辑。
实现基于应用程序的 Cookie 是实现直通模式的另一个使用案例。在此使用案例中，后端目标为经过身份验证的客户端发送 Cookie，客户端可以使用这些 Cookie 进行通信。这样可以确保后端目标无需为每个传入请求处理整个证书链。您可以使用开源库在后端目标上实现 Cookie，然后实现基于 Cookie 跟踪客户端身份验证状态的逻辑。
监控
应用程序负载均衡器为发送到负载均衡器的所有请求提供连接日志。这些日志将发送到 Amazon Simple Storage Service (Amazon S3) 存储桶，并包含客户端 IP 地址、TLS 密码的详细信息以及请求被拒绝时的错误代码等详细信息。有关详细信息，请参阅应用程序负载均衡器的连接日志。
应用程序负载均衡器的 mTLS 支持的 CloudWatch 指标的完整列表可在适用于应用程序负载均衡器的 CloudWatch 指标中获取。
ALB 的 mTLS 模式与网络负载均衡器 (NLB) 的比较
如果您拥有 HTTPS 应用程序并想执行应用程序级路由，我们建议您考虑使用 ALB。例如，对 HTTPS 请求执行加权轮询负载均衡将使您可以创建蓝绿部署。ALB 还将允许您卸载 TLS/mTLS 的操作。由于 ALB 会终止客户端的 TLS 会话，您需要为 ALB 上传证书。
另一方面，NLB 在传输层（OSI 模型的第 4 层）上运行，为 TCP/UDP 连接提供低延迟负载均衡。对于 HTTPS 应用程序，如果您设有特定的安全合规性规则，需要服务器终止客户端的 TLS 连接，我们建议使用网络负载均衡器 (NLB)。
表 1 对应用程序负载均衡器的直通模式和验证模式以及 NLB 做了比较，并介绍了每个选项的注意事项。
| ALB + mTLS 验证模式 | ALB + mTLS 直通模式 | NLB | |
| 客户端身份验证 | 由 ALB 完成，由 AWS 托管 | 由后端目标完成，由客户托管 | 由后端目标完成，由客户托管 |
| 客户端的 SSL/TLS 会话终止 | 在 ALB，由 AWS 托管 | 在 ALB，由 AWS 托管 | 在后端目标，由客户托管 |
| 路由规则功能 | ALB 的应用程序级路由规则 | ALB 的应用程序级路由规则 | NLB 的基于端口和协议的路由规则 |
结论
在这篇博文中，我们讨论了应用程序负载均衡器的 mTLS 验证和直通模式，以及使用每种模式时的注意事项。当您想要使用 ALB 进行客户端身份验证时，可以在应用程序负载均衡器上使用 mTLS 验证模式。当您想要控制后端目标上的客户端身份验证时，mTLS 直通模式最适合。使用信任库需额外付费，启用 mTLS 时还需要考虑应用程序负载均衡器的定价问题。有关详细信息，请访问弹性负载均衡定价页面。
此功能现已推出，请立即试用；如果有任何问题或意见，请联系 AWS Support 向我们提供反馈。
关于作者
Jamie Wenzel
Jamie 是 EC2 联网领域的首席 SA 网络专家。Jamie 是应用程序联网组织的一员，致力于应用程序联网产品和服务设计。他是 re:invent、re:inforce、loft、summit 和 twitch 的狂热公开演讲者。他在亚马逊的工作时间已超过 6 年，热衷于帮助个人和组织踏上云之旅。
William Wang
William Wang 是 AWS 弹性负载均衡（ELB）团队的高级产品经理。他热衷于帮助客户使用 ELB 构建应用程序，以实现高可用性、可扩展性和增强的安全性。他在西雅图工作，喜欢阅读和讨论从云安全性、联网到人工智能和机器学习的任何话题。
Ankit Chadha
Ankit 是一名联网专家解决方案架构师，为 AWS 的 AWS 行业客户提供支持。他喜欢为客户构建安全和可扩展的网络架构。在业余时间，Ankit 喜欢打板球、陪伴自己的猫咪和阅读传记。
2024 年 4 月 3 日：这篇博文中删除了对 CloudFront 指标的不准确引用。