ROOT CA如何验证签名？

假设使用https时,浏览器向服务器发出请求,服务器返回其证书,包括公钥和CA签名.

此时,浏览器会要求其CA验证给定的公钥是否真的属于服务器？

这个验证是如何通过浏览器上的Root证书完成的？

举个例子:假设serverX从CA"rootCA"获得了证书.浏览器具有本地存储的rootCA副本.当浏览器ping serverX并以其公钥+签名回复时.现在根CA将使用其私钥解密签名并确保它真的是serverX？

它是如何工作的？

1> Mecki..：

---

您的服务器有一个密钥对,包括私钥和公钥.服务器当然永远不会发出私钥,但每个人都可以获得公钥.公钥嵌入在证书容器格式中.此容器包含与包装密钥相关的元信息,例如服务器的IP地址或域名,此IP地址/域名的所有者,所有者的电子邮件地址,密钥创建时间,时长是有效的,可用于其目的,等等.

整件事由一个值得信赖的机构签署.受信任的机构,即证书颁发机构(CA)也具有私钥/公钥对.您向他们提供您的证书,他们验证容器中的信息是否正确,并通过他们的私钥对其进行签名,只有他们有权访问.默认情况下,CA的公钥安装在用户系统上,大多数众所周知的CA已包含在您喜欢的操作系统或浏览器的默认安装中.

当用户连接到您的服务器时,您的服务器使用私钥对某些数据进行签名,将签名数据与其证书一起打包并将所有内容发送到客户端.客户现在可以做什么？首先,它可以使用刚刚发送的证书中的公钥来验证签名数据.由于只有私钥的所有者能够以公钥正确验证签名的方式正确签署数据,因此它知道签署了这条数据的人,这个人也拥有收到的私钥.公钥.到目前为止一切顺利.

但是什么阻止黑客拦截数据包,用他使用不同证书签署的数据替换签名数据,并用自己的证书替换证书？没有.这就是为什么在验证签名数据之后(或在验证之前),客户端验证收到的证书是否具有有效的CA签名.使用已安装的公共CA密钥,它验证所接收的公钥是否已由已知CA签名.否则它被拒绝,因为黑客可能已经取代了它.

最后但并非最不重要的是,它会检查证书本身的信息.IP地址或域名是否真正与客户端正在与之交谈或相信与之交谈的服务器的IP地址或域名相匹配？如果没有,有些东西可疑!人们可能会问:什么阻止黑客只是创建自己的密钥对,只是将您的域名或IP地址放入他的证书中,然后由CA签名？容易:如果他这样做,没有CA会签署他的证书.要获得CA签名,您必须证明您确实是此IP地址或域名的所有者.黑客不是所有者,因此他不能证明这一点,因此他不会得到签名.所以这不会奏效.

好吧,如果黑客注册他自己的域名,为此创建证书,并由CA签名,该怎么办？这项工作,他将获得CA签名,这是他的域名,没问题.但是,在攻击你的连接时他不能使用它.如果他使用此证书,浏览器将立即看到已签名的公钥用于域example.net,但它当前正在与example.com通信,而不是同一个域,因此有些东西可能会再次出现问题.

---

浏览器在线检查的唯一内容(如果可以)是CA证书是否仍然有效.每个CA服务都运行一个证书撤销服务器,浏览器可以询问某个证书是否仍然有效或已被撤销; 这是通过OCSP协议完成的:http://tinyurl.com/pcjk2 Certs包含要询问的OCSP服务器的地址.

---

好答案!但是我有另一个相关的问题...引用:"最知名的CA已经包含在您最喜欢的操作系统或浏览器的默认安装中." 我想知道浏览器如何扩展默认的已知CA？它会自动检查Web服务吗？或者它只会在下一版本的浏览器版本中这样做？

---

CA证书与浏览器或操作系统一起提供.Firefox,Chrome,Opera都有自己的CA证书副本,Internet Explorer和Safari使用安装在Windows或OS X中的CA证书.没有什么能阻止浏览器同时使用自己的副本和操作系统范围的证书(我提到的一些甚至可能那).您只能通过更新浏览器,更新操作系统或手动安装它们来获得新的CA证书(下载然后将它们添加到浏览器或您的操作系统,两者都可以).

2> 小智..：

---

服务器证书使用CA的私钥进行签名.浏览器使用CA的公钥来验证签名.浏览器和CA之间没有直接通信.

重要的一点是浏览器附带公共CA密钥.在Firefox中,请参阅工具 - >选项 - >高级 - >加密 - > ViewCertificates->当局.因此浏览器事先知道它可以信任的所有CA.

如果您不理解这一点,请查看非对称密码学和数字签名的基础知识.