【学习笔记】SSL证书安全机制之证书链

本文主要是介绍【学习笔记】SSL证书安全机制之证书链，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言：CA会给成千上万的Server签发证书，但CA不会直接去签发这么多证书，本篇将给出解释

一、证书链原理解析

我们需知，CA证书预装在浏览器里（不仅仅是浏览器，也可以是一切可以联网的软件）；有些时候，操作系统有自己的信任源，软件会用本地的CA证书；无论哪种方式，CA证书是安装在Client的软件里。
- 如果CA的私钥被泄露了，唯一可以移除对CA的信任的方法是运行某些软件更新。
  - 事实情况是我们很少会及时更新软件，现在很多应用程序都是用SSL来连接互联网，如果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》）