ssl-certificate - 客户端如何在 SSL 中验证服务器证书？

Question

我阅读了很多关于这个主题的内容，所有“详细”的解释似乎都错过了一步:
对于客户端验证服务器，它执行以下操作(根据我的理解):

它从服务器获取证书。证书将包含公钥和数字签名。

2?) 客户端使用公钥验证签名是否正常。
这就是我感到困惑的原因。说我是中间的那个人。我可以连接到服务器并获取服务器提供给我的任何信息，然后将其转发给客户端。客户如何知道谁实际出示了证书？
以下是我也知道的一般情况:

客户端知道公钥。它用它加密消息并将其发送到服务器。

服务器知道私钥，解密消息，然后发回。

现在客户端可以与服务器共享对称 key 。

中间的人可以在场，但这没关系，因为没有私钥就无法解密数据。

那么这与证书中的(静态？)数字签名有什么关系呢？
请帮助我了解该特定步骤(验证签名)。

Answer 1

一开始，您向证书颁发机构 (CA) 请求证书
通过提供 CSR(由域详细信息和服务器的公钥组成)。
然后 CA 将通过以下步骤颁发数字证书:

CSR 使用散列算法签名，即 SHA256/md5 生成散列(CSR)

然后使用其签名者私钥之一对散列的 CSR 进行加密。即，加密(哈希(CSR))

然后 encrypted(hash(CSR)) 附加到 CSR 上，我们可以称之为数字证书

数字证书 = CSR + 加密(哈希(CSR))

证书验证:
服务器在建立 TLS 连接时向用户代理发送证书。
然后用户代理(浏览器)查看证书，检查证书是否来自受信任的 CA。
如果它来自受信任的 CA，那么用户代理会解析证书，我们将在其中获得 CSR 和加密(哈希(CSR))。

现在我们使用散列算法创建 CSR 的散列，我们生成散列(CSR)。

Encrypted(hash(CSR)) 使用 CA 的公钥解密。由此，我们将得到哈希(CSR)。

如果步骤 4 中的 hash(CSR) == 步骤 5 中的 hash(CSR)，则验证证书。
有关 TLS 中的密码套件和协商过程的更多详细信息，请参阅 TLS 握手过程。