ssl 证书是如何验证的？

Question

安全验证 ssl 证书所需的一系列步骤是什么？我（非常有限）的理解是，当您访问 https 站点时，服务器会向客户端（浏览器）发送证书，浏览器从该证书中获取证书的颁发者信息，然后使用该信息联系颁发者，并以某种方式进行比较有效性证书。

• 具体是如何完成的？
• 如何让它免受中间人攻击？
• 是什么阻止了一些随机的人设置自己的验证服务以用于中间人攻击，所以一切“看起来”都是安全的？

Answer 1

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

您可以检查和/或更改受信任的机构列表。通常，您这样做是为了为您信任的地方当局添加证书 - 例如您工作的公司或您就读的学校等等。

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

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

Answer 2

这是一个非常简单的解释：

1. 您的 Web 浏览器会下载 Web 服务器的证书，其中包含 Web 服务器的公钥。此证书使用受信任的证书颁发机构的私钥签名。

2. 您的网络浏览器安装了所有主要证书颁发机构的公钥。它使用此公钥来验证 Web 服务器的证书是否确实由受信任的证书颁发机构签名。

3. 证书包含 Web 服务器的域名和/或 IP 地址。您的 Web 浏览器与证书颁发机构确认证书中列出的地址是它与其建立开放连接的地址。

4. 您的 Web 浏览器会生成一个共享对称密钥，该密钥将用于加密此连接上的 HTTP 流量；这比对所有内容使用公钥/私钥加密要有效得多。您的浏览器使用 Web 服务器的公钥加密对称密钥，然后将其发回，从而确保只有 Web 服务器可以解密它，因为只有 Web 服务器拥有它的私钥。

请注意，证书颁发机构 (CA) 对于防止中间人攻击至关重要。但是，即使是未签名的证书也会阻止某人被动地监听您的加密流量，因为他们无法访问您的共享对称密钥。

Answer 3

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

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

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

Answer 4

你说过

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

客户不必与发行人核实，因为有两件事：

1. 所有浏览器都预装了所有主要 CA 公钥的列表
2. 证书已签名，并且该签名本身足以证明该证书有效，因为客户端可以自行确保该证书是真实的，而无需联系颁发者的服务器。这就是非对称加密的美妙之处。

请注意，2. 不能没有 1。

这在我前段时间做的big diagram中有更好的解释

（跳到底部的“什么是签名？”）

Answer 5

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

警告：兔子洞很深:)。

Answer 6

我知道下面很长，但它很详细，但足够简单。仔细阅读，我保证你会开始发现这个话题并不那么复杂。

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

其次，简单来说，证书颁发机构 (CA) 提供为您创建证书的服务。如何？他们使用某些值（CA 的颁发者名称、您的服务器的公钥、公司名称、域等）并使用他们的 SUPER DUPER ULTRA SECURE SECRET 私钥并加密此数据。此加密数据的结果是一个签名。

所以现在 CA 给你一个证书。证书基本上是一个文件，其中包含前面提到的值（CA 的颁发者名称、公司名称、域、服务器的公钥等），包括签名（即后面值的加密版本）。

现在，说了这么多，这里有一个非常重要要记住的部分：您的设备/操作系统（Windows、Android 等）几乎保留了所有主要/受信任 CA 的列表以及他们的公钥（如果您认为这些公钥用于解密证书中的签名，您是正确的！）。

好的，如果您阅读了上面的内容，现在这个顺序示例将变得轻而易举：

1. Example-Company 要求 Example-CA 为他们创建证书。
2. Example-CA 使用他们的超级私钥签署此证书并将证书提供给 Example-Company。
3. 明天，互联网用户-Bob 使用 Chrome/Firefox/等。浏览至https://example-company.com。现在的大多数（如果不是全部）浏览器都希望从服务器返回证书。
4. 浏览器从 example-company.com 获取证书。证书说它是由 Example-CA 颁发的。碰巧 Bob 的操作系统已经在其受信任的 CA 列表中包含了 Example-CA，因此浏览器获取了 Example-CA 的公钥。请记住：这一切都发生在 Bob 的电脑/手机/等设备中，而不是通过网络。
5. 现在浏览器解密证书中的签名。最后，浏览器将解密的值与证书本身的内容进行比较。 如果内容匹配，则表示签名有效！

为什么？想想看，只有这个公钥才能解密签名，使内容看起来像私钥加密之前的内容。

中间人攻击怎么样？

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

假设黑客简拦截了互联网用户鲍勃的请求，并用她自己的证书进行了回复。但是，hacker-Jane 仍然非常小心地在证书中声明颁发者是 Example-CA。最后，黑客简记得她必须在证书上包含一个签名。但是 Jane 使用什么密钥来签署（即创建证书主要内容的加密值）证书？？？？？？

因此，即使黑客 Jane 使用自己的密钥签署了证书，您也可以看到接下来会发生什么。浏览器会说：“好的，这个证书是由 Example-CA 颁发的，让我们用 Example-CA 的公钥解密签名”。解密后，浏览器发现证书内容完全不匹配。因此，浏览器会向用户发出非常明确的警告，并表示它不信任该连接。