如何验证ssl证书?

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

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

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

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

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

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

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

3. 该证书包含web服务器的域名和/或ip地址。您的web浏览器向证书颁发机构确认，证书中列出的地址就是与其有开放连接的地址。

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

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

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

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

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

你说过

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

.比较证书的有效性

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

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

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

这可以在我不久前做的大的图中更好地解释

(请跳过“什么是签名?”在底部)

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

警告:兔子洞很深:)。

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

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

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

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

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

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

1. Example-Company要求Example-CA为他们创建一个证书。
2. Example-CA使用他们的超级私钥签署此证书，并将证书授予Example-Company。
3. 明天，互联网用户鲍勃将使用Chrome/Firefox等。来浏览到https://example-company.com。现在大多数(如果不是全部的话)浏览器都希望从服务器返回证书。
4. 浏览器从example-company.com获取证书。证书上说它是由Example-CA颁发的。恰好Bob的操作系统的受信任CA列表中已经有了Example-CA，因此浏览器获得了Example-CA的公钥。记住:这一切都发生在Bob的电脑/手机等。，而不是通过电线。
5. 所以现在浏览器解密证书中的签名。最后，浏览器将解密的值与证书本身的内容进行比较。如果内容匹配，则表示签名有效!

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

那中间的人攻击呢?

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

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

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