客户端如何验证SSL中的服务器证书？

Question

我读了很多关于这个主题的内容以及所有＆＃34;详细的＆＃34;解释似乎错过了一步：

对于客户端验证服务器，它执行以下操作（根据我的理解）：

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

2？）客户端使用公钥验证签名是否正常。

这就是为什么我感到困惑。说我是中间人。我可以连接到服务器并获取服务器提供给我的任何信息，然后将其转发给客户端。客户如何告诉谁实际出示证书？

这也是我一般都知道的：

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

2）服务器知道私钥，解密消息并将其发回。

3）现在客户端可以与服务器共享对称密钥。

4）中间的人可以在场，但这并不重要，因为没有私钥就无法解密数据。

那么这与证书中的（静态??）数字签名有什么关系？

请帮助我了解具体步骤（验证签名）。

（编辑格式化）

Answer 1

一开始，您向证书颁发机构 (CA) 请求证书 通过提供 CSR（由域详细信息和服务器公钥组成）。

然后 CA 将通过以下步骤颁发数字证书：

1. CSR 使用哈希算法签名，即 SHA256/md5 生成哈希（CSR）

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

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

数字证书 = CSR + 加密(hash(CSR))

---

证书验证：

服务器在建立 TLS 连接时向用户代理发送证书。

然后用户代理（浏览器）查看证书，检查证书是否来自受信任的 CA。

如果它来自受信任的 CA，那么用户代理会解析证书，我们将在其中获取 CSR 并加密（hash(CSR)）。

4. 现在我们使用散列算法创建一个 CSR 的散列，我们生成一个散列（CSR）。

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

如果第 4 步中的 hash(CSR) == 第 5 步中的 hash(CSR)，则验证证书。

有关 TLS 中的密码套件和协商过程的更多详细信息，请参阅 TLS 握手过程。

Answer 2

经过进一步的挖掘，我发现了我所缺少的东西。

服务器显示带有签名的证书文件。我缺少的是“数字签名算法”或类似的算法。

假设P是公钥，R是私有的。

基本上，如果H是输入而R是私钥，我们得到C作为输出。

因为C是数字签名算法的结果，我们可以使用公共P​​和输出C来获得H.

这回答我的问题的原因是： 假设某人假装是服务器并且能够准确地重播C.确保证书看起来有效，但C不能继续进行，因为其他消息将使用公共P​​进行加密。

这是我从未见过的答案。

我在这里找到了相关信息： http://www.jscape.com/blog/what-is-a-digital-signature

Answer 3

我想我可以就这个过程为你回答这个问题。 1.客户端发送TLS请求，其中包含有关它可以支持的信息。 2.服务器接收它并说我可以支持它并提供由Verisign或Go Daddy签署的公钥和服务器证书等。 3.客户端接收它，在其本地信任存储中验证基于有效性的信息，在服务器公共中创建包含在服务器中的秘密密钥，然后它们形成安全的加密信道。为了使一些人能够使用MITM，他们需要具有CA根签名证书，其中包含确切的CN，位置，城市和站点名称等。这是不可能的，因为CA没有分配双证书。