当使用https时，浏览器向服务器发出请求，服务器返回其证书，包括公钥和CA签名。
此时，浏览器会要求其CA验证给定的公钥是否真的属于服务器？
如何通过浏览器上的Root证书完成此验证？
举个例子： 假设serverX从CA“rootCA”获得了证书。浏览器具有本地存储的rootCA副本。当浏览器ping serverX并以其公钥+签名回复时。现在，根CA将使用其私钥解密签名并确保它真的是serverX？
它是如何工作的？
答案 0 :(得分：71)
您的服务器会创建一个密钥对，包含私钥和公钥。当然，服务器永远不会发出私钥，但每个人都可以获得公钥的副本。公钥嵌入在证书容器格式（X.509）中。该容器包括与包装密钥相关的元信息，例如，服务器的IP地址或域名，该服务器的所有者，电子邮件联系地址，创建密钥的时间，有效期，可用于的目的以及许多其他可能的值。
整个容器由受信任的证书颁发机构（= CA）签名。 CA还具有私钥/公钥对。您向他们提供您的证书，他们验证容器中的信息是否正确（例如，联系信息是否正确，该证书是否真正属于该服务器），最后使用其私钥对其进行签名。需要在用户系统上安装CA的公钥。大多数众所周知的CA证书已包含在您最喜欢的操作系统或浏览器的默认安装中。
当用户连接到您的服务器时，您的服务器使用私钥对一些随机数据进行签名，将签名数据与其证书（=公钥+元信息）打包在一起并将所有内容发送到客户端。客户可以用这些信息做什么？
首先，它可以使用刚刚发送的证书中的公钥来验证签名数据。由于只有私钥的所有者能够以公钥正确验证签名的方式正确签署数据，因此知道签署了这条数据的人，这个人也拥有私钥。收到公钥。
但是什么阻止黑客拦截数据包，用他使用不同证书自己签名的数据替换签名数据，并用自己的证书替换证书？答案完全没有。
这就是为什么在验证签名数据之后（或在验证之前），客户端验证收到的证书是否具有有效的CA签名。使用已安装的公共CA密钥，它验证所接收的公钥是否已由已知且希望信任的CA签名。默认情况下，未签名的证书不受信任。用户必须在其浏览器中明确信任该证书。
最后，它会检查证书本身的信息。 IP地址或域名是否与客户端当前正在与之交谈的服务器的IP地址或域名真正匹配？如果没有，有些东西可疑！
人们可能想知道：什么阻止黑客只是创建自己的密钥对，只是将您的域名或IP地址放入他的证书中，然后由CA签名？答案很简单：如果他这样做，CA就不会签署他的证书。要获得CA签名，您必须证明您确实是此IP地址或域名的所有者。黑客不是所有者，因此他不能证明这一点，因此他不会得到签名。
但是如果黑客注册他自己的域名，为此创建证书，并由CA签名呢？这项工作，他将获得CA签名，毕竟这是他的域名。但是，他不能用它来破解你的连接。如果他使用此证书，浏览器将立即看到已签名的公钥用于域example.net，但它当前正在与example.com通信，而不是同一个域，因此再次出错。
答案 1 :(得分：7)
服务器证书使用CA的私钥进行签名。浏览器使用CA的公钥来验证签名。浏览器和CA之间没有直接通信。
重要的一点是浏览器附带公共CA密钥。在Firefox中，请参阅工具 - >选项 - >高级 - >加密 - >视图证书 - >权限。因此浏览器事先知道它可以信任的所有CA.
如果您不理解这一点，请查看非对称密码学和数字签名的基础知识。
答案 2 :(得分：3)
Certs基于使用像RSA这样的非对称加密。您有两个密钥，通常称为私钥和公钥。使用私钥对加密的内容只能使用公钥解密。 （实际上，反之亦然。）
你可以认为证书就像是护照或驾驶执照：它是一张凭证，上面写着“这就是我自己;你可以相信它，因为它是由你信任的某人（比如威瑞信）给我的。”这是通过“签名”完成的，可以使用证书颁发机构的公钥来计算。如果数据是CA最初获得的数据，则可以验证证书。
证书包含有关证书所有者的标识信息。当您收到它时，您使用您信任的权限所知的密钥组合来确认您收到的证书是有效的，并且因此您可以推断您信任颁发证书的人。
答案 3 :(得分：0)
您的浏览器不会要求CA验证，而是它具有本地存储的根证书的副本，并且它将使用标准加密程序来验证证书是否真的有效。
这就是为什么当您自行签署证书时，您的证书无效，尽管技术上有CA要求，但您可以将自签名CA复制到您的计算机上，从那时起它就会信任您的自签名证书
CACert.org也有同样的问题，它有有效的证书，但由于浏览器的列表中没有根证书，因此在用户下载根CA并将其添加到浏览器之前，证书会生成警告。