一个根证书颁发机构如何验证签名?

41
在使用https时,浏览器向服务器发出请求,服务器返回其证书,包括公钥和CA签名。
此时,浏览器将要求其CA验证所给出的公钥是否真的属于该服务器。
根证书是如何在浏览器上进行验证的呢?
举个例子:假设serverX从CA“rootCA”获得了证书。浏览器本地存储有rootCA的副本。当浏览器联系serverX并收到其公钥+签名时,根CA将使用其私钥解密该签名并确保它确实来自serverX。
这就是它是如何工作的吗?

相关论文:HTTPS拦截的安全影响 - Pablo Bianchi
4个回答

97

您的服务器创建一个密钥对,由私钥和公钥组成。当然,服务器永远不会泄露私钥,但每个人都可以获得公钥的副本。公钥嵌入到证书容器格式(X.509)中。该容器包含与封装密钥相关的元信息,例如服务器的IP地址或域名,服务器所有者,电子邮件联系地址,密钥创建时间,有效期限,可用于哪些目的以及许多其他可能的值。

整个容器由可信任的证书颁发机构(CA)签名。CA也拥有私钥/公钥对。您将证书交给他们,他们验证容器中的信息是否正确(例如,联系信息是否正确,该证书是否真的属于该服务器),最后使用其私钥对其签名。CA的公钥需要安装在用户系统上。大多数知名的CA证书已经包含在您最喜欢的操作系统或浏览器的默认安装中。

现在,当用户连接到您的服务器时,您的服务器使用私钥对一些随机数据进行签名,将该已签名数据与其证书(=公钥+元信息)打包在一起并发送给客户端。客户端可以用这些信息做什么呢?

首先,它可以使用刚刚接收到的证书中的公钥来验证签名数据。由于只有私钥的所有者能够以正确的方式签署数据,以使公钥可以正确验证签名,因此客户端将知道签署此数据的人也拥有接收到的公钥的私钥。

但是,如果黑客截取了数据包,并用不同的证书替换已签名数据并且还替换了证书,该怎么办呢?答案很简单,就是没有什么阻止它的措施。

这就是为什么在验证签名数据之后(或在其验证之前),客户端验证接收到的证书是否具有有效的CA签名。使用已安装的公共CA密钥,它验证已接收的公钥是否已经由已知且希望信任的CA签名。默认情况下,不信任未签名的证书。用户必须在浏览器中显式地信任该证书。

最后,它会检查证书本身的信息。IP地址或域名是否真的与客户端当前正在通信的服务器的IP地址或域名匹配?如果不匹配,就有可疑之处!

人们可能会想:有什么阻止黑客创建自己的密钥对,并将您的域名或IP地址放入他的证书中,然后让CA签署它?简单的答案是:如果他这样做,没有CA会签署他的证书。要获得CA签名,您必须证明您确实是此IP地址或域名的所有者。黑客不是所有者,因此他无法证明,并因此无法获得签名。

但是,如果黑客注册自己的域名、为其创建证书并由CA签署呢?这是可行的,他将获得CA签名,毕竟这是他的域名。但是,他不能用它来攻击您的连接。如果他使用这个证书,浏览器将立即看到已签名的公钥是为example.net域名,但它当前正在与example.com域名交流,不是相同的域名,因此再次出现问题。


3
好的回答!但我有另一个相关的问题... 引用:“大多数知名的CA已经包含在您喜爱的操作系统或浏览器的默认安装中。” 我想知道浏览器如何扩展默认已知的CA?它会自动检查Web服务吗?还是只会在下一个版本的浏览器发布时这样做? - forestclown
3
CA证书通常随浏览器或操作系统一起提供。Firefox、Chrome和Opera都包含自己的CA证书副本,而Internet Explorer和Safari使用安装在Windows或OS X中的CA证书。没有什么能阻止浏览器同时使用自己的副本和操作系统范围内的证书(我提到的一些浏览器甚至可能会这样做)。您只能通过更新浏览器、更新操作系统或手动安装它们(下载然后将其添加到浏览器或操作系统中,两者都可以)来获取新的CA证书。 - Mecki
4
浏览器在线检查的唯一内容(如果可以的话)是CA证书是否仍然有效。每个CA服务都运行一个证书吊销服务器,在这里浏览器可以查询某个证书是否仍然有效或已被吊销。这是通过OCSP协议完成的:http://tinyurl.com/pcjk2 证书包含要查询的OCSP服务器的地址。 - Mecki
“IP欺骗”呢? - Wafeeq
1
@GulluButt CA证书要么是您操作系统的一部分(例如,Windows有一组CA证书,macOS / iOS也有),要么是浏览器的一部分(例如,Firefox带有自己的一组CA证书)。它们不会自动更新,它们会作为操作系统更新或浏览器更新的一部分进行更新,并且这些更新希望是安全的,因为如果它们不安全,攻击者可能会给您一个伪造的浏览器,在启动时劫持您的整个系统。 - Mecki
显示剩余4条评论

13

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

重要的是,浏览器随附公共CA密钥。因此,浏览器预先知道所有可信任的CA。

如果您不理解这一点,请查阅非对称加密和数字签名的基础知识。


假设这个内容是正确的:这是我看过/见过的最好的技术高管摘要(想象一下那些已经熟悉公私钥并且不关心不必要细节的有经验的CTO),在阅读/观看了许多臃肿的文本和动画描述之后。简短、简明、全面,直接进入关键点。非常感谢。 - Johnny Utahh
1
浏览器使用CA的公钥来验证签名。这是我无法理解的部分。它如何做到这一点? - waxingsatirical
@waxingsatirical - 这是我的理解:1)公钥用于验证私钥签名(请注意,为了使TLS/SSL客户端进行此验证,需要未编码证书和所述证书的签名,并由TLS/SSL服务器提供),2)利用#1中提到的过程来验证TLS/SSL证书 - Johnny Utahh

3
证书基于使用非对称加密,如RSA。您有两个键,通常称为私钥和公钥。使用私钥加密的内容只能使用公钥解密。(实际上,反之亦然)。
您可以将证书视为护照或驾照:它是一种凭据,表明“这就是我;您可以信任它,因为它是由您信任的某人(如Verisign)给予我的。” 这是通过“签名”完成的,可以使用证书颁发机构的公钥计算。如果数据与CA最初收到的数据相同,则可以验证证书。
证书包含有关证书所有者的身份信息。当您接收它时,您使用来自受信任机构的已知密钥组合来确认您收到的证书有效,并且您可以推断出您信任颁发证书的人。

服务器的签名应该很容易获得:只需向其发送https请求即可。如果服务器Y以这种方式获取了服务器X的签名,那么它不能冒充服务器X吗? - Sesh
不,当您的浏览器连接时,它使用独特的起始点(Diffie-Hellman密钥交换),除非ServerY拥有用于基于浏览器发送给您的内容计算公钥的证书的私钥,否则它无法冒充serverX。 - X-Istence
Sesh,在特定条件下它可以执行的操作被称为“中间人”攻击。这使它可以扮演客户端和服务器,拦截所有通信。但是,有针对此类攻击的保护措施。请搜索“中间人”攻击和SSL以获取详细信息。 - Charlie Martin

0

你的浏览器不会询问CA进行验证,而是在本地存储了根证书的副本,然后使用标准的加密程序来验证该证书是否真正有效。

这就是为什么当你自我签署证书时,你的证书是无效的,尽管技术上有一个CA可以询问,当然你可以将自签署CA复制到计算机中并从此信任自签署的证书。

CACert.org也有同样的问题,它拥有有效的证书,但由于浏览器没有它的根证书列表,所以其证书会生成警告,直到用户下载根CA并将其添加到其浏览器中为止。


我不太清楚。是这样的,serverX从CA rootCA获得了证书。浏览器在本地存储了rootCA证书。因此,当浏览器ping serverX时,它会回复其公钥+签名。根CA将使用其私钥解密签名并确保它确实是serverX吗? - Sesh
不,它检查的是签名,我可以使用我的私钥签署一些内容,使其验证通过我的公钥。因此,本地存储的根CA实际上是CA的公共部分。如果远程服务器发送证书,则该证书将具有某个签名,然后该签名可以被验证。 - X-Istence
通过数学计算对CA的公共部分进行验证,以验证CA的私有部分实际上签署了证书。 - X-Istence

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接