深入理解 mTLS 双向认证
在前面的文章中，我们学习了：
- 证书和 CA 解决了公钥分发的信任问题，让客户端能验证服务器身份。
- TLS 密钥协商算法 解决了密钥交换的前向保密问题，让客户端和服务端可以安全地通信。
这两个机制结合起来，让 HTTPS 能够建立安全的加密通信。
但整个过程中有一个问题：服务器只能验证客户端发送的数据是加密的，但无法确认客户端的身份。
在普通的网站访问场景下，这不是问题。用户通过浏览器访问网站，身份验证通常在应用层完成（比如输入用户名密码）。
但在另一些场景中，这就成了问题：
场景 1：微服务之间的调用
假设你的订单服务要调用支付服务的 API，支付服务怎么知道调用者确实是可信的订单服务，而不是攻击者伪造的请求？
场景 2：没有内置认证的分布式系统
像 Zookeeper、etcd 这类分布式协调服务，早期版本没有完善的用户认证机制。如果直接暴露在网络中，任何人都可以连接并操作数据。
场景 3：IoT 设备认证
物联网设备（如智能传感器）需要连接到云端服务器，服务器如何确认连接的设备是合法的，而不是被篡改的设备？
在这些场景中，我们需要的不仅是加密通信，还需要双向的身份认证：客户端要知道服务器是谁，服务器也要知道客户端是谁。
这就是 mTLS（Mutual TLS，双向 TLS）要解决的问题。
什么是 mTLS
在标准的 TLS 连接中（比如 HTTPS），认证是单向的：客户端验证服务器的证书，但服务器不验证客户端的身份。
网站访问场景下，这没问题。服务器不需要在网络层验证客户端的身份，因为用户会在应用层验证身份（比如输入用户名密码）。
mTLS 在 TLS 的基础上增加了客户端认证：客户端也要向服务器出示证书。
在 TLS 握手过程中，服务器在返回自己的证书后，会额外发送一个请求，要求客户端提供证书。客户端返回证书，服务器验证证书的有效性（证书链、有效期、吊销状态等），验证通过后才接受连接。
这样双方都用证书证明身份，建立相互信任。
mTLS 的核心理念是：证书就是身份。
这就像办理银行业务时，你需要出示由政府（CA）颁发的身份证（Client Certificate），银行需要出示由政府颁发的执照（Server Certificate），你们才能建立信任关系。
mTLS 握手流程
TLS 握手我们在前文已经详细讲过了，这里重点说明 mTLS 与标准 TLS 的区别。
标准 TLS vs mTLS
两者的主要区别在于证书交换阶段：
标准 TLS（单向认证）：
mTLS（双向认证）：