在进一步讨论之前,我们需要先引入证书链的概念。提一个问题:您的浏览器如何知道是否应该信任网站的SSL证书? 受信任的根的任何下级证书都是受信任的。这在技术层面上是如何工作的呢?
当你访问一个网站时,浏览器会查看它的SSL证书,并快速的验证证书的真实性。浏览器会检查证书的有效期、确保证书没有被撤销、验证证书的数字签名。
浏览器循着证书链对证书进行身份验证的操作。要获得颁发的SSL证书,首先要生成证书签名请求(CSR)和私钥。最简单的迭代,你将CSR发送给证书颁发机构,然后它使用来自其根的私钥签署SSL证书并将其发送回来。
现在,当浏览器看到SSL证书时,它会看到证书是由其根存储中的一个受信任根颁发的(或者更准确地说,使用根的私钥签名)。因为它信任根,所以它信任根签名的任何证书。为了使你更容易理解,上述内容我们作了简化,将服务器证书直接链到根。现在加入中间证书。
证书颁发机构不会直接从它们的根证书颁发服务器/叶子证书(最终用户SSL证书)。这些根证书太宝贵了,直接颁发风险太大了。
因此,为了保护根证书,CAs通常会颁发所谓的中间根。CA使用它的私钥对中间根签名,使它受到信任。然后CA使用中间证书的私钥签署和颁发终端用户SSL证书。这个过程可以执行多次,其中一个中间根对另一个中间根进行签名,然后CA使用该根对证书进行签名。这些链接,从根到中间到叶子,都是证书链。下面是证书链的可视化图形,为了便于理解,简化复杂的过程,我们只在证书链中加入一个中间证书,实际的证书链通常要复杂得多。
你可能会注意到,当CA颁发SSL证书时,它还会发送需要安装的中间证书。这样,浏览器就能够完成证书链,并将服务器上的SSL证书链接回它的一个根。浏览器和操作系统处理不完整链的方式各不相同。有些只会在中间证书丢失时发出问题并报错,而另一些则会保存和缓存中间证书,以防它们日后派上用场。
数字签名有点像数字形式的公证。当根证书对中间证书进行数字签名时,它实际上是将部分信任转移给中间证书。因为签名直接来自受信任根证书的私钥,所以它是自动受信任的。
任何时候,只要向浏览器或设备提供SSL证书,它就会接收证书以及与证书关联的公钥。它通过公钥验证数字签名,并查看它是由谁生成的(即由哪个证书签名的)。你现在可以开始把这些拼凑起来。当您的浏览器在网站上验证最终用户SSL证书时,它使用提供的公钥来验证签名并在证书链上向上移动一个链接。重复这个过程:对签名进行身份验证,并跟踪签名的证书链,直到最终到达浏览器信任存储中的一个根证书。如果它不能将证书链回其受信任的根,它就不会信任该证书。
这其实很简单。Root CA(根CA)是拥有一个或多个可信根的证书颁发机构。这意味着它们根植于主流浏览器的信任存储中。中间CAs或子CAs是由中间根发出的证书颁发机构。 它们在浏览器的信任存储中没有根,它们的中间根会链回到一个受信任的第三方根。这有时称为交叉签名。
正如我们前面讨论的,CA并不直接从它们的根颁发证书。他们通过颁发中间证书并使用中间证书签署证书,增加根证书的安全性。这有助于在发生误发或安全事件时最小化和划分损害,当安全事件发生时,不需要撤销根证书,只需撤销中间证书,使从该中间证书发出的证书组不受信任。
我们刚描述了根和中间体,涉及到证书颁发机构、证书链和加密签名的信任模型,本质上归结到一个词:PKI或公钥基础设施。到目前为止,我一直避免过多地使用这个术语,除非你深入了解一些细节,否则它看起来非常抽象。
文章参考自:
FreeBuf.COM
自制Https证书并在Spring Boot和Nginx中使用
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)