如果这个问题真的很天真，请原谅，但我尽可能多地搜索，却找不到相关的答案。
在过去的三天里，我一直在努力了解https是如何工作的。这些天以前，我只知道对称和非对称密码学是如何工作的。现在是我了解这两种方法如何应用于ssl-https并实现所谓的数据加密和服务器身份验证的时候了。
关于数据加密和防止中间人攻击，一切都很清楚
我似乎不完全理解服务器身份验证是如何工作的，所以我们将非常感谢您的帮助。
到目前为止，我的理解如下：
当客户端通过https连接到服务器时，服务器会发送一个由CA证书签名的证书。此服务器证书是一个文本文件，包含有关服务器的信息(名称、所有者电子邮件、公钥等)以及数字签名。
此签名是由CA私钥加密的服务器信息内容的哈希。
客户端通过再次自己生成服务器信息的哈希并使用CA的公钥解密签名来检查签名的有效性。如果解密的签名值与生成的哈希值相同，则签名和证书随后是有效的。
请注意，公私加密方案具有双重性质。消息可以用公钥加密，也可以用私钥解密。相同的消息可以用私钥加密，也可以用公钥解密。
我们需要记住的是，证书是一个静态的、不可更改的文件。对文件的任何更改都将导致签名不匹配。
我现在将描述一种欺骗https:的方法
假设有一个网址为的ebanking网站https://wwww.TheBank.com/ebanking(公共IP=195.134.0.1)我连接到此URL，浏览器将获得服务器证书。(银行)
同时，我还是一家网吧的老板。我的网吧有自己的路由器、DNS和DCHP服务器，我有控制这些服务器的知识。它还有一个网络服务器。
我将网络服务器配置为拥有ip 195.134.0.1，与银行的相同我创建了一个到路由器的路由，该路由将195.134.0.1的连接请求发送到我的web服务器我将DNS配置为将上述银行URL指向195.134.0.1(我的网络服务器)我在我的网络服务器上放置了一个欺诈性的银行网站。对于此网站上的任何连接，我指示web服务器将我之前下载的证书发送到客户端。(银行)
一个用户来到我的咖啡馆，连接到我的网络，并试图连接到这家银行。我的服务员把银行的证明发给他。他的浏览器将确认证书的有效性，因为它确实是有效的，并允许连接到我的假网站，因为它的URL、IP和主机名与真实的相同。
所以我的诈骗是成功的。
当然，这个安全漏洞太明显了，不可能是真的。这意味着我还不了解服务器身份验证过程中的某些内容。有人能向我解释一下我在这里缺了什么吗？
一位用户来到我的咖啡馆，连接到我的网络，并试图连接到这家银行。我的服务员把银行的证明发给他。他的浏览器将确认证书的有效性，因为它确实是有效的，并允许连接到我的假网站，因为它的URL、IP和主机名与真实的相同。
一旦他的浏览器确认了有效性，它就会知道银行的真实公钥，因为它在证书中。由于您的服务器无法使用与该公钥对应的私钥对任何内容进行签名，也无法解密使用该公钥加密的任何内容，因此您根本无法模拟银行。你所能做的就是让用户相信银行的真实身份，而你不能冒充它。
我认为你缺少的关键是，证书的主要目的是让可信机构将真实世界的身份绑定到公钥，这样只有真实世界身份的所有者知道相应的私钥。
theBank.cer是公钥
您不能使用它来解密或签名任何内容。
此签名是服务器信息内容的散列，由CA私钥加密。
客户通过再次出示来检查签名的有效性他自己的-服务器信息的散列，并使用解密签名CA的公钥。如果解密的签名值与随后生成的哈希、签名和证书有效的
这或多或少是RSA的情况，但DSA不是，DSA只是签名(不加密)。
一般来说，您不应该谈论使用私钥进行"加密"。这没有任何意义，因为任何人都可以用公钥解密(因为它是公共的)。加密就是隐藏信息。
您可以使用私钥进行签名和解密/解密。您可以使用公钥对签名进行加密和验证。
如果你混淆了什么时候需要加密，什么时候需要签名(尽管算法与RSA非常相似)，你最终可能会设计出不提供任何安全性的系统。
更一般地说，公钥证书(X.509证书，甚至PGP证书)的目的是将身份(例如服务器主机名)绑定到公钥。(请参阅Security.SE上的此问题。)
我的网络服务器将接收的数据将由公众加密银行密钥
请注意，SSL/TLS流量不是使用证书的私钥加密的，而是在SSL/TLS握手期间协商的共享密钥。
在SSL/TLS握手期间，该公钥用于加密预主密钥或对其他参数进行签名(取决于密码套件)，这些参数最终向客户端证明它正在与拥有该公钥私钥的服务器通信。
由于证书还将服务器名称绑定到公钥，因此客户端就知道它正在与正确的服务器通信。
这就是为什么验证(a)证书是可信的，(b)证书颁发给客户端想要连接的服务器名称是很重要的