注意：我非常匆忙地写了原始答案，但是从那时起，它变成了一个相当受欢迎的问题/答案，因此我对其进行了扩展并使其更加精确。
TLS功能
“ SSL”是最常用于指代该协议的名称，但SSL特别指的是Netscape在90年代中期设计的专有协议。“ TLS”是基于SSL的IETF标准，因此我将在答案中使用TLS。这些天来，很可能您的网络上几乎所有安全连接实际上都使用TLS，而不是SSL。
TLS具有以下功能：
- 加密您的应用程序层数据。（在您的情况下，应用程序层协议为HTTP。）
- 向客户端验证服务器。
- 向服务器验证客户端。
＃1和＃2很常见。＃3不太常见。您似乎专注于＃2，因此我将解释这一部分。
认证方式
服务器使用证书对客户端进行身份验证。证书是包含有关网站信息的数据[1]的斑点：
- 域名
- 公钥
- 拥有它的公司
- 何时发行
- 到期时
- 谁发行的
- 等等。
您可以通过使用证书中包含的公钥来加密只能由相应私钥解密的消息来实现机密性（上述＃1），该私钥应安全地存储在该服务器上。[2] 我们将此密钥对称为KP1，这样以后就不会感到困惑。您还可以验证证书上的域名是否与您访问的站点相匹配（上面的＃2）。
但是，如果对手可以修改发送到服务器或从服务器发送的数据包，又如果该对手修改了向您提供的证书并插入了自己的公钥或更改了其他重要细节，该怎么办？如果发生这种情况，对手可以拦截和修改您认为已安全加密的任何消息。
为了防止这种攻击，证书由其他人的私钥加密签名，这样签名可以被拥有相应公钥的任何人验证。让我们将此密钥对称为KP2，以明确它们与服务器使用的密钥不同。
证书颁发机构
那么谁创造了KP2？谁签署了证书？
稍微简化一点，证书颁发机构创建KP2，然后他们出售使用私钥为其他组织签名证书的服务。例如，我创建了一个证书，并向Verisign这样的公司付款，用他们的私钥对其进行签名。[3] 由于除了Verisign之外没有其他人可以访问此私钥，因此我们谁也不能伪造此签名。
为了验证该签名，我个人将如何使用KP2中的公钥？
好了，我们已经看到证书可以持有公钥，并且计算机科学家喜欢递归，那么为什么不将KP2公钥放入证书并以这种方式分发呢？起初听起来有些疯狂，但实际上这就是它的工作原理。继续使用Verisign示例，Verisign生成一个证书，其中包括有关他们是谁，允许他们签名的事物类型（其他证书）以及它们的公钥的信息。
现在，如果我拥有该Verisign证书的副本，则可以使用该副本来验证要访问的网站的服务器证书上的签名。容易吧？！
好吧，不是那么快。我必须从某处获得Verisign证书。如果有人欺骗了Verisign证书并在其中放置了自己的公钥怎么办？然后他们可以在服务器证书上伪造签名，然后我们就回到了开始的位置：中间人攻击。
证书链
继续进行递归思考，我们当然可以引入第三证书和第三密钥对（KP3），并使用它们来对Verisign证书进行签名。我们将其称为证书链：该链中的每个证书都用于验证下一个证书。希望您已经可以看到，这种递归方法一直都是乌龟/证书。它在哪里停下来？
由于我们不能创建无限数量的证书，因此证书链显然必须停在某处，这可以通过在自签名链中包含一个证书来完成。
当您从头部爆炸中捡起脑部物质时，我会稍等片刻。自签名？！
是的，在证书链的末尾（又名“根”），将有一个证书使用其自己的密钥对进行签名。这样可以消除无限递归问题，但不能解决身份验证问题。任何人都可以创建一个在其上写有任何内容的自签名证书，就像我可以创建一个虚假的普林斯顿大学文凭一样，该证书说我在政治，理论物理学方面都学过三门专业，然后应用对接，然后在底部签名了自己的名字。
解决此问题的方法（有点令人兴奋）只是选择您明确信任的一组自签名证书。例如，我可能会说：“我信任此Verisign自签名证书”。
有了明确的信任，现在我可以验证整个证书链。无论链中有多少证书，我都可以一直验证每个签名直到根。当我到达根目录时，可以检查该根证书是否是我明确信任的证书。如果是这样，那么我可以信任整个链条。
授予的信任
TLS中的身份验证使用授予信任的系统。如果我想雇用汽车修理工，我可能不相信我发现的任何随机修理工。但是也许我的朋友担保某个机械师。因为我信任我的朋友，所以我可以信任那个机械师。
当您购买计算机或下载浏览器时，计算机附带它明确信任的几百个根证书。[4] 拥有并运营这些证书的公司可以通过签署其证书将信任授予其他组织。
这远非一个完美的系统。有时，CA可能会错误地颁发证书。在这种情况下，可能需要吊销证书。吊销是棘手的，因为颁发的证书将始终是密码正确的；必须使用带外协议才能确定哪些先前有效的证书已被吊销。实际上，其中一些协议不是很安全，许多浏览器也不会对其进行检查。
有时，整个CA都受到威胁。例如，如果您要闯入Verisign并窃取其根签名密钥，那么您可以欺骗世界上任何证书。请注意，这不仅会影响Verisign客户：即使我的证书是由Thawte（Verisign的竞争对手）签署的，也没关系。我的证书仍可以使用Verisign的受感染签名密钥来伪造。
这不只是理论上的。它发生在野外。DigiNotar被黑客入侵，随后破产。Comodo也遭到了黑客攻击，但直到今天，他们仍在经营。
即使没有直接破坏CA，该系统中也存在其他威胁。例如，政府使用法律强制手段强迫CA对伪造的证书进行签名。您的雇主可以在您的员工计算机上安装自己的CA证书。在这些各种情况下，您期望“安全”的流量实际上对于控制该证书的组织是完全可见/可修改的。
建议了一些替代方案，包括Convergence，TACK和DANE。
尾注
[1] TLS证书数据是根据X.509标准格式化的。X.509基于ASN.1（“抽象语法符号＃1”），这意味着它不是二进制数据格式。因此，必须将X.509 编码为二进制格式。DER和PEM是我所知道的两种最常见的编码。
[2]实际上，协议实际上会切换到对称密码，但这是一个细节，与您的问题无关。
[3]大概是，CA在签署证书之前实际上会验证您的身份。如果他们没有这样做，那么我可以为google.com创建证书，然后要求CA对其进行签名。有了该证书，我可以将与google.com的任何“安全”连接置于中间位置。因此，验证步骤是CA运作中非常重要的因素。不幸的是，目前尚不清楚世界各地数百个CA的验证过程多么严格。
[4]请参阅Mozilla的受信任CA列表。
