我读了很多关于这个主题的内容以及所有＆＃34;详细的＆＃34;解释似乎错过了一步：
对于客户端验证服务器，它执行以下操作（根据我的理解）：
1）它从服务器获取证书。证书将包含公钥和数字签名。
2？）客户端使用公钥验证签名是否正常。
这就是为什么我感到困惑。说我是中间人。我可以连接到服务器并获取服务器提供给我的任何信息，然后将其转发给客户端。客户如何告诉谁实际出示证书？
这也是我一般都知道的：
1）客户端知道公钥。它用它加密消息并将其发送到服务器。
2）服务器知道私钥，解密消息并将其发回。
3）现在客户端可以与服务器共享对称密钥。
4）中间的人可以在场，但这并不重要，因为没有私钥就无法解密数据。
那么这与证书中的（静态??）数字签名有什么关系？
请帮助我了解具体步骤（验证签名）。
（编辑格式化）
答案 0 :(得分：3)
一开始，您向证书颁发机构 (CA) 请求证书 通过提供 CSR（由域详细信息和服务器公钥组成）。
然后 CA 将通过以下步骤颁发数字证书：
CSR 使用哈希算法签名，即 SHA256/md5 生成哈希（CSR）
然后使用其签名者私钥之一对散列的 CSR 进行加密。即加密(hash(CSR))
然后将encrypted(hash(CSR))附加到CSR上，我们可以称之为数字证书
数字证书 = CSR + 加密(hash(CSR))
证书验证：
服务器在建立 TLS 连接时向用户代理发送证书。
然后用户代理（浏览器）查看证书，检查证书是否来自受信任的 CA。
如果它来自受信任的 CA，那么用户代理会解析证书，我们将在其中获取 CSR 并加密（hash(CSR)）。
现在我们使用散列算法创建一个 CSR 的散列，我们生成一个散列（CSR）。
Encrypted(hash(CSR)) 使用 CA 的公钥解密。由此，我们将得到哈希（CSR）。
如果第 4 步中的 hash(CSR) == 第 5 步中的 hash(CSR)，则验证证书。
有关 TLS 中的密码套件和协商过程的更多详细信息，请参阅 TLS 握手过程。
答案 1 :(得分：2)
经过进一步的挖掘，我发现了我所缺少的东西。
服务器显示带有签名的证书文件。我缺少的是“数字签名算法”或类似的算法。
假设P是公钥，R是私有的。
基本上，如果H是输入而R是私钥，我们得到C作为输出。
因为C是数字签名算法的结果，我们可以使用公共P和输出C来获得H.
这回答我的问题的原因是： 假设某人假装是服务器并且能够准确地重播C.确保证书看起来有效，但C不能继续进行，因为其他消息将使用公共P进行加密。
这是我从未见过的答案。
我在这里找到了相关信息： http://www.jscape.com/blog/what-is-a-digital-signature
答案 2 :(得分：-1)
我想我可以就这个过程为你回答这个问题。 1.客户端发送TLS请求，其中包含有关它可以支持的信息。 2.服务器接收它并说我可以支持它并提供由Verisign或Go Daddy签署的公钥和服务器证书等。 3.客户端接收它，在其本地信任存储中验证基于有效性的信息，在服务器公共中创建包含在服务器中的秘密密钥，然后它们形成安全的加密信道。为了使一些人能够使用MITM，他们需要具有CA根签名证书，其中包含确切的CN，位置，城市和站点名称等。这是不可能的，因为CA没有分配双证书。