客户端预先播种了SSL证书颁发机构的公钥存储。必须有一个信任链，从服务器的证书到中间授权机构，再到所谓的“根”证书之一，才能使服务器受到信任。

您可以检查和/或更改可信权威的列表。通常你这样做是为了给你信任的地方权威机构添加一个证书，比如你工作的公司或你就读的学校等等。

预播种列表根据您使用的客户端而有所不同。大型SSL证书供应商确保他们的根证书在所有主要浏览器中($$$)。

“中间猴子”攻击是“不可能的”，除非攻击者拥有受信任根证书的私钥。由于相应的证书被广泛部署，这种私钥的暴露通常会对电子商务的安全性产生严重影响。正因为如此，这些私钥受到了非常非常严密的保护。

这里有一个非常简单的解释:

Your web browser downloads the web server's certificate, which contains the public key of the web server. This certificate is signed with the private key of a trusted certificate authority. Your web browser comes installed with the public keys of all of the major certificate authorities. It uses this public key to verify that the web server's certificate was indeed signed by the trusted certificate authority. The certificate contains the domain name and/or ip address of the web server. Your web browser confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection. Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection; this is much more efficient than using public/private key encryption for everything. Your browser encrypts the symmetric key with the public key of the web server then sends it back, thus ensuring that only the web server can decrypt it, since only the web server has its private key.

注意，证书颁发机构(CA)对于防止中间人攻击至关重要。然而，即使是未签名的证书也会阻止别人被动地监听您的加密通信，因为他们没有办法访问您的共享对称密钥。

值得注意的是，除了购买证书(如上所述)，你还可以免费创建自己的证书;这被称为“自签名证书”。自签名证书和购买的证书之间的区别很简单:购买的证书已经由您的浏览器已经知道的证书颁发机构签署。换句话说，您的浏览器可以很容易地验证所购买证书的真实性。

不幸的是，这导致了一种常见的误解，即自签名证书本质上不如GoDaddy和Verisign等商业CA销售的证书安全，并且如果使用它们，您必须接受浏览器警告/异常;这是不正确的。

如果您安全地分发自签名证书(或CA证书，如bobince建议的那样)并将其安装在将使用您的站点的浏览器中，那么它就与购买的证书一样安全，并且不容易受到中间人攻击和证书伪造的攻击。显然，这意味着只有在只有少数人需要安全访问您的网站(例如，内部应用程序，个人博客等)时才可行。

你说过

浏览器从中获取证书的颁发者信息 证书，然后使用它来联系颁发者，并以某种方式 比较证书的有效性。

客户不必与发行人核实，原因有两点:

所有浏览器都有一个预安装的所有主要ca公钥列表 证书是签名的，签名本身就足以证明证书是有效的，因为客户端可以自己确定，而无需联系颁发者的服务器，该证书是可信的。这就是非对称加密的美妙之处。

注意2。没有1是不行的。

我之前画的这张大图解释得更好

(跳到最下面的“什么是签名?”)

如果你更注重技术，这个网站可能就是你想要的:http://www.zytrax.com/tech/survival/ssl.html

警告:兔子洞很深:)。

我知道下面的内容很长，但它很详细，也足够简化。仔细阅读，我保证你会发现这个话题并没有那么复杂。

首先，任何人都可以创建两个键。一个用于加密数据，另一个用于解密数据。前者可以是私钥，后者可以是公钥，以及VICERZA。

其次，简单地说，证书颁发机构(CA)为您提供创建证书的服务。怎么做?它们使用特定的值(CA的颁发者名称、服务器的公钥、公司名称、域等)，并使用它们的SUPER DUPER ULTRA SECURE SECRET私钥并加密此数据。这个加密数据的结果是一个签名。

现在CA返回给您一个证书。证书基本上是一个包含前面提到的值的文件(CA的颁发者名称、公司名称、域、服务器的公钥等)，包括签名(即后一个值的加密版本)。

现在，说了这么多，这里有一个非常重要的部分要记住:你的设备/操作系统(Windows, Android等)几乎保存了所有主要/受信任的CA及其公钥的列表(如果你认为这些公钥用于解密证书中的签名，那么你是正确的!)

好吧，如果你读了上面的，这个顺序的例子现在就很简单了:

Example-Company asks Example-CA to create for them a certificate. Example-CA uses their super private key to sign this certificate and gives Example-Company the certificate. Tomorrow, internet-user-Bob uses Chrome/Firefox/etc. to browse to https://example-company.com. Most, if not all, browsers nowadays will expect a certificate back from the server. The browser gets the certificate from example-company.com. The certificate says it's been issued by Example-CA. It just so happens to be that Bob's OS already has Example-CA in its list of trusted CA's, so the browser gets Example-CA's public key. Remember: this is all happening in Bob's computer/mobile/etc., not over the wire. So now the browser decrypts the signature in the certificate. FINALLY, the browser compares the decrypted values with the contents of the certificate itself. IF THE CONTENTS MATCH, THAT MEANS THE SIGNATURE IS VALID!

为什么?考虑一下，只有这个公钥才能以一种方式解密签名，使内容看起来像私钥加密它们之前的内容。

那中间的人攻击呢?

这是创建上述标准的主要原因之一(如果不是主要原因)。

假设黑客jane拦截了互联网用户bob的请求，并用她自己的证书回复。然而，hacker-Jane仍然谨慎地在证书中声明颁发者是Example-CA。最后，黑客jane记得她必须在证书上签名。但是Jane使用什么密钥对证书?????进行签名(即创建证书主要内容的加密值)

所以就算黑客简用自己的密钥签署了证书，你也知道接下来会发生什么。浏览器会说:“好，这个证书是由Example-CA颁发的，让我们用Example-CA的公钥解密签名”。解密后，浏览器注意到证书内容根本不匹配。因此，浏览器给用户一个非常明确的警告，它说它不相信这个连接。