TLS 1.3 协议的握手部分有三个目标：

• 交换证书；
• 让服务器确认客户端确实拥有与提供的公共证书相关联的密钥，而无需交换密钥；
• 交换临时密钥。

第 1 部分 - 证书的信任

Certificate客户端发送带有消息的证书。

服务器确定证书是否来自受信任的来源。它验证客户端证书的签名，然后验证每个中间证书的签名，直到从服务器端的受信任证书列表或受信任的证书颁发机构 (CA) 中找到受信任的证书。

伪代码：

1. Alice（客户端）将她的公共证书发送给 Bob（服务器）以及证书链。
2. Bob 对证书进行哈希处理。
3. Bob 使用链中的上层证书解密证书。
4. Bob 比较了两个结果；如果它们匹配，则 Bob 有证据证明该证书确实是使用上层证书签署的。
5. Bob 继续遍历链（步骤 2、3、4），直到找到受信任的证书。

第 2 部分 - 客户的信任

客户端发送Certificate Verify消息：

struct {
  SignatureScheme algorithm;
  opaque signature<0..2^16-1>;
} CertificateVerify;

告诉使用的signature scheme散列函数和签名算法。

由signature客户端生成并由服务器验证。实际签名的数据为客户端和服务器所知，因此不会重新发送（它是空格、上下文字符串、零字节和先前的消息）。

伪代码：

1. Alice（客户端）生成一个非对称密钥对。
2. 一个受信任的机构签署她的公钥，产生一个公共证书。
3. Alice 对数据进行哈希处理。
4. Alice 使用她的加密密钥（她的私钥）对散列进行加密。
5. Bob（服务器）从之前的消息中知道：Alice 的公共证书和证书链。
6. Alice 向 Bob 发送：签名、散列函数和签名算法。
7. Bob 对数据进行哈希处理。
8. Bob 使用 Alice 的公共证书解密签名。
9. Bob 比较了两个结果；如果它们匹配，Bob 就有了签名与数据相关联的证据，并且 Alice 的私钥生成了签名。

现在，Alice 必须对她的密钥保密，并且请求之间的数据必须不同，以避免 Eve 用相同的数据和相同的签名重放请求。

我希望它可以帮助您更好地理解。

参考资料：
http ://www.garykessler.net/library/crypto.html#why3
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html
https://nodejs.org/ api/crypto.html#crypto_class_sign
https://www.tutorialspoint.com/cryptography/cryptography_digital_signatures.htm

服务器有一些信任根，它使用它，或者根据应用程序，它可能有一个 CA 的证书，或者只是那个客户端的证书，固定。

无论如何，它要么通过其信任存储并检查客户端证书是否由其存储中的某些东西签名，或者如果它被固定，它只会检查它配置为检查的一个 CA 或证书。