前言:CA会给成千上万的Server签发证书,但CA不会直接去签发这么多证书,本篇将给出解释
一、证书链原理解析
- 我们需知,CA证书预装在浏览器里(不仅仅是浏览器,也可以是一切可以联网的软件);有些时候,操作系统有自己的信任源,软件会用本地的CA证书;无论哪种方式,CA证书是安装在Client的软件里。
- 如果CA的私钥被泄露了,唯一可以移除对CA的信任的方法是运行某些软件更新。
- 事实情况是我们很少会及时更新软件,现在很多应用程序都是用SSL来连接互联网,如果CA泄露了私钥,我们安装更新就会允许其他人截断链接并偷取我们所有数据。
- 系统信任的是软件里的签名,只有软件更新才能撤销信任。
- 如果CA的私钥被泄露了,唯一可以移除对CA的信任的方法是运行某些软件更新。
- 取而代之的是,签名通常都委托给中间CA(Intermediate CA),初始的CA也称作根CA(Root CA),那现在就是中间CA负责给Server签发证书。
- 这创建了安全“控制点”(Control Points),意味着,如果中间CA私钥泄露了,根CA组要做的就是撤销委托的签名权(而不需要运行任何联网的软件更新)。
- 另一件需要做的事,是增加根CA私钥的安全性
- 根CA的私钥应该很少被使用(使用越多,越不安全)
- 根CA私钥存储在“air gapped”系统(不连接互联网的计算机),或HSMs(Hard Security Modules,比如密码机)
- 实际上,实际(根CA的)私钥被拆分成许多部分,然后被存储在许多HSMs,然后交给许多不同的人。以这种方式,整个的私钥不会出现在一个地方,如果某个人泄露了他那部分的私钥,但并不会泄露整个密钥
- 由于以上原因,签名权一般都委托给中间CA
- 上面讨论的是安全性,另一方面,这样也会允许CA组织边界。例如,中间CA将签名权委托给其他下级CA,如图所示的绿色CA(负责给欧洲地区的网站签发证书),和红色CA(负责给美国网站签发证书);也有可能绿色CA负责给软件或代码进行代码签,而红色CA负责给网站签发SSL证书。
- 这样,就形成了一个链条(Chain)联通到根CA(Root CA),这就是我们所谓的证书链(Certificate Chain)
- Root Certificate Authority(根CA)
- 一切始于根CA
- 根CA拥有一对公钥和私钥
- 私钥的安全是至关重要的
- 根CA还拥有自签发的证书
- 该证书预装在浏览器中(如果不想信任根CA证书可以从浏览器里卸载,用户一般没权限进行该操作,浏览器厂商可以,反之亦然)
- 提供“Trust Anchor”(信任锚)
- Intermediate Certificate Authority(ICA,中间CA)
- 中间CA是独立的组织,他们有自己的公钥和私钥
- 也有他们自己的(自签发)证书
- 提交CSR给根CA来请求证书(和用户申请证书相同),根CA会签发证书给中间CA
- 证书由签发CA(Issuing CA)所签名
- 这一过程可以进行无数遍,也就是说理论上可以有无限制的中间CA(但实际上,目前一般只有1个中间CA,最多2个且是交叉验证),每个中间CA都有自己的公钥和私钥。
- 需要注意的是,必须形成一个连通到“chain”
- Server Certificate(服务器证书)
- 证书链的终点,一般称作“End Entity”(最终实体),或者“Leaf Certificate”(叶证书),又或者“Server Certificate”(服务器证书)
- 服务器获取证书的过程和我们之前讲述的一样
- Server生成公钥和私钥
- Server生成CSR文件
- Server将CSR文件发送给CA
- Server收到由CA签发的证书
- 完成链条
- Subject(主体)和Issuer(颁发者)
- 每张证书都有Subject和Issuer,这构成了通往根CA的链条(Chain)。Subject验证了证书的主体(Subject),比如freessl.cn,Issuer验证了是谁创建了该证书,比如某中间CA(ICA)。该中间CA也有Subject(中间CA)和Issuer(上级ICA或者根CA);根CA的证书是自签的,因而Subject和Issuer都是自己。
- 哪张证书应该发送给Client?
- 一般情况下,Client要连接到Server,而Server要发送正确的证书来避免出现SSL错误
- 在此之前,Client已经预装了根CA的证书(预装在联网的软件里)
- Server必须发送它最终实体证书(也就是服务器证书)
- Server必须发送每一个证书链中的中间证书(因为,Client要验证服务器证书的签名,而这个签名由红色ICA创建,我们就需要该ICA的公钥来验证签名,但此时,Client并不信任红色ICA。因此,如果Client只收到了服务器证书,Client并不会信任该证书。)
- Client会验证每张证书的签名(具体地,收到红色ICA的公钥,那么就可以验证蓝色证书的签名;粉色证书的公钥可以验证红色证书的签名;而预装的根CA证书可以验证粉色证书的签名;一个链条下来,最终Client可以信任蓝色证书)
- Server还能发送根CA证书(如果想就可以选择发送)
- 然而,在验证阶段,Client会忽略根证书
- “信任锚”必须来自预装的东西,并且在Client软件中被预先信任
- 那么为什么要发送根证书呢?(不是说不需要验证根吗?)原因在于,它允许Client轻易地添加根CA证书(如果Client想这样),这样的例子不是在标准的互联网网站中,而是出现在公司CA(Corporate CA)环境里。例如,公司有许多内部网站资源,如果员工没有预装公司的根CA证书,浏览器访问内网网站的时候就会报错。(前面将PKI的时候,提到企业内部也是PKI,详情请看《SSL证书之PKI》)
- 然而,在验证阶段,Client会忽略根证书
二、证书链示例
我们可以查看本站点的证书,如下:
可以看到证书链分3层,最上面的是DigiCert的根证书,中间是GeoTrust(DigiCert旗下)的中间证书,最下面的也就是我们的服务器证书,可以看到是*.csdn.net通配符证书。
参考文献
1、网站:Practical Networking.net:Practiacl TLS