如何验证ssl证书？

Question

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

• 这究竟是怎么做到的？
• 这个过程如何让它免受中间人攻击？
• 是什么阻止了一些随机的人设置自己的验证服务以用于中间人攻击，所以一切都“看起来”安全？

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

为了提高认识并鼓励像我这样的小型博主来保护自己，我写了一个入门级教程，更详细地解释了证书背后的概念以及如何安全地创建和使用自我签名证书（包含代码示例和屏幕截图）。

Answer 3

你说那个

  

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

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

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

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

的情况下完成

我在前面提到的这个big diagram中有更好的解释

（跳到＆＃34;签名是什么？＆＃34;在底部）

Answer 4

客户端有预先存储的SSL证书颁发机构的公钥。服务器的证书必须有一条信任链​​，通过中间权限直到一个所谓的“根”证书，才能使服务器受信任。

您可以检查和/或更改受信任的权限列表。通常，您这样做是为您信任的地方当局添加证书 - 例如您所在的公司或您就读的学校或不参加的学校。

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

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

Answer 5

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

警告：兔子洞深入：）。

Answer 6

我知道下面的内容很长，但很详细，但已足够简化。请仔细阅读，我保证您不会发现本主题很复杂。

首先，任何人都可以创建2个密钥。一种用于加密数据，另一种用于解密数据。前者可以是私钥，而后者可以是公钥AND 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 / etc。浏览到https://example-company.com。如今，大多数（如果不是全部）浏览器将期望从服务器返回证书。
4. 浏览器从example-company.com获得证书。该证书表明它是由Example-CA颁发的。碰巧的是，鲍勃的操作系统在其受信任CA的列表中已经包含Example-CA，因此浏览器将获得Example-CA的公钥。请记住：这都是在鲍勃的计算机/手机/等设备中发生的，而不是通过电线进行的。
5. 因此，现在浏览器将证书中的签名解密。最终，浏览器将解密后的值与证书本身的内容进行比较。 如果内容匹配，则表示签名有效！

为什么？仔细考虑一下，只有这个公钥才能以一种使内容看起来像在私钥对其进行加密之前一样的方式来解密签名。

中间人攻击怎么样？

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

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

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