事情比这更复杂，这张图有一些缺陷，混合了本地存储的东西和交换的东西。
请查看https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake，特别是“客户端身份验证TLS握手”案例。
总而言之：

• 在某个时刻，服务器要求客户端发送证书（这并不总是需要的，因此服务器发送特定消息来请求证书，CertificateRequest）
• 然后，客户端使用包含其证书的Certificate消息进行回复
• 在该阶段，服务器已经可以基于所提供的证书来决定它是否想要进一步;在那个阶段，其他人也可以发送相同的证书，因为它是公开的。但是下面解释了为什么它在TLS握手中不能进一步工作
• 在来自服务器的X1 M2 N1 X消息（其包含稍后将用于真正加密应用数据的交换的各种密码数据）之后，
• 客户端发送CertificateVerify消息，该消息是在握手中先前交换的TLS消息上计算的签名，使用与客户端证书关联的私有密钥
• 接收到该消息的服务器可以再次检查它正在与真实的客户机通话，因为通过尝试用客户机公钥（包含在证书中）来验证签名，它将知道远程方是否确实具有正确的相关联的私钥。

因此，只要私钥保持私有，攻击者就不能通过窃取证书来冒充客户端（在另一种情况下，为了验证服务器，也存在同样的保护措施）。如果私钥被窃取，以上所有操作都将失败。
在这一点上不需要理解密码签名的所有细节，只是系统以这样的方式设计，即由密钥之一加密的所有内容只能由另一个密钥解密：如果某人用其私钥加密数据，那么任何人都可以用其公钥（根据定义，公钥是公开的;一般来说，你只需要分发它，但这里没有，因为公钥包含在证书中，证书是在握手之前交换的）;当然，这对于保密性是无用的（任何人都可以看到加密的内容），但是这是认证的基础，因为如果解密工作，则意味着发送者具有与用于解密该内容的公共密钥相关联的私有密钥。
请注意，随着TLS 1.3作为一个新标准刚刚推出，TLS交换中消息的数量和性质略有变化，但上述加密保证（用私钥对某些内容进行签名，以便远程方可以使用关联的公钥进行双重检查）仍然有效。

除了Patrick's应答之外，在mTLS过程中还比较时间戳。如果传入的时间戳超出了某个限制，则会放弃会话，因此您截获的数据包将变得无用。
请https://en.wikipedia.org/wiki/Mutual_authentication#Defenses。