数字证书的基础知识
数字证书是用来认证公钥持有者身份合法性的电子文档，以防止第三方冒充行为。数字证书由 CA（Certifacate Authority） 负责签发，关键内容包括 颁发s者、证书有效期、使用者组织、使用者公钥 等信息。数字证书涉及到一个名为 PKI（Public Key Infrastructure） 的规范体系，包含了数字证书格式定义、密钥生命周期管理、数字签名及验证等多项技术说明，不在这篇笔记中详细展开。
我们借助下面的流程，看看 CA 是如何签发一张证书，使用者又是如何验证这样证书的。这又涉及到了数字签名技术，数字签名技术又是基于公钥密码技术。
现实世界中，签名是针对承诺的一种表现形式，手手段可以通过手写签字或盖扣印章；而在数字世界中，签名仍然是为了表示承诺，只是手段变成了二进制。
好，我们来看看 CA 数字签名包括两个过程：签发证书（Signing） 和 验证证书（Verification）
签发证书的过程
- 撰写证书元数据：包括 签发人(Issuer)、地址、签发时间、有效期 等，还包括证书持有者(Owner)基本信息，比如 DN(DNS Name，即证书生效的域名)、 Owner 公钥 等信息
- 使用通用的 Hash 算法（如SHA-256）对证书元数据计算生成 数字摘要
- 使用 Issuer 的私钥对该数字摘要进行加密，生成一个加密的数字摘要，也就是Issuer的 数字签名
- 将数字签名附加到数字证书上，变成一个 签过名的数字证书
- 将签过名的数字证书与 Issuer 的公钥，一同发给证书使用者（注意，将公钥主动发给使用者是一个形象的说法，只是为了表达使用者最终获取到了 Issuer 的公钥）
验证证书的过程
- 证书使用者获通过某种途径（如浏览器访问）获取到该数字证书，解压后分别获得 证书元数据 和 数字签名
- 使用同样的Hash算法计算证书元数据的 数字摘要
- 使用 Issuer 的公钥 对数字签名进行解密，得到 解密后的数字摘要
- 对比 2 和 3 两个步骤得到的数字摘要值，如果相同，则说明这个数字证书确实是被 Issuer 验证过合法证书，证书中的信息（最主要的是 Owner 的公钥）是可信的
上述是对数字证书的签名和验证过程，对普通数据的数字签名和验证也是利用了同样的方法。
我们再来总结一下“签发证书”与“验证证书”两个过程，Issuer（CA）使用 Issuer 的私钥 对签发的证书进行数字签名，证书使用者使用 Issuser 的公钥 对证书进行校验，如果校验通过，说明该证书可信。
由此看出，校验的关键是 Issuer 的公钥，使用者获取不到 Issuer 的私钥，只能获取到 Issuer 的公钥，如果 Issuer 是一个坏家伙，谁来证明 Issuer 的身份 是可信的？
这就涉及到一个信任链条了，也是这篇笔记本身要讲述的事情，证书链。
信任链介绍
前面的“证书之什么是数字签名？”简单科普了一下为什么要使用证书。其实这些以及后面要科普的都是整个公钥基础设施PKI（Public key infrastructure）体系中一部分。下面介绍什么是数字证书的信任链
证书链是一个有序的证书列表，包含SSL证书和证书颁发机构（CA）证书，使接收方能够验证发送方和所有CA是否值得信任。链或路径以SSL证书开头，链中的每个证书都由链中下一个证书标识的实体签名。
链的结构
链终止于根CA证书。必须验证链中所有证书的签名，直至根CA证书。根CA证书始终由CA本身签名。
下图说明了从证书所有者到根CA的证书路径
上图从下往上介绍依次有
-
根证书：根证书（Root Certificate）的签名（Root CA’s signature）是用根私钥（Root CA‘s private key）签的。所以验证根证书签名（Root CA’s signature）要用根公钥（Root CA’s public key）才能验证通过。这种情况就叫做自签名（self-sign）。
-
中介证书： 中介证书（Intermediate Certificate）里面包含了根证书的名称（Issuer’s /root CA’s name）。中介证书里面的签名（Issuer’s signature）是用根私钥（Root CA‘s private key）签的，所以需要根公钥（Root CA’s public key）才能验证通过。
-
终端实体证书：终端实体证书（End-entity Certificate）里面包含了中介证书的名称（Issuer’s / CA’s name）。终端实体证书里面的签名（Issuer’s signature）是用中介私钥（Owner‘s private key）签的，所以需要中介公钥（Owner’s public key）才能验证通过。
实际场景
还是以Google为例，在浏览器上访问 “www.google.com” 域名，地址连左侧有一个小锁的标志，点击就能查看百度的数字证书，如下图所示（使用的是Chrome浏览器）
在图片的顶部，我们看到这样一个层次关系：
GlobalSign Root CA -> GTS CA 101 -> *.google.com
分别对应： 根证书 -> 中介证书 -> 终端实体证书
结合实际的使用场景对证书链进行一个归纳：
- 为了获取 end-user 的公钥，需要获取 end-user 的证书，因为公钥就保存在该证书中
- 为了证明获取到的 end-user 证书是可信的，就要看该证书是否被 intermediate 机构认证
- 有了intermediate机构的数字签名，需要继续往上验证，即查看是否存在上一级权威认证机构的数字签名
- 信任链条的最终是Root CA，他采用自签名，对他的签名只能无条件的信任
信任链模型
常见有四种类型用于使用PKI实现信任模型。
A.分层信任模型（Hierarchical Trust Model）：
分层模型或树模型是实现PKI的最常见模型。顶部的根CA提供所有信息，中间CA在层次结构中是下一个，并且它们仅信任根提供的信息。根CA还信任层次结构中其级别的中间CA.
这种安排允许在分层树的所有级别进行高级别的控制，这可能是希望扩展其证书处理能力的大型组织中最常见的实现。分层模型允许严格控制基于证书的活动。
B.桥接信任模型（Bridge Trust Model）：
在桥接信任模型中，我们在Root CA之间有许多P2P关系，根CA之间可以相互通信并允许交叉证书。该实施模型允许在组织（或部门）之间建立认证过程。
在此模型中，每个中间CA仅信任其上方和下方的CA，但可以扩展CA结构，而无需创建其他CA层。组织之间的额外灵活性和互操作性是桥模型的主要优势。
C.混合信任模型（Hybrid Trust Model）：
有时您需要在某个部分链接两个或更多组织或部门，并将其他部分分开。当您需要信任两个组织的某些部分，但您不希望在组织的其他部分中建立信任。在这些时候，混合信任模型可以是最适合您的模型。构建混合信任结构时，您可以非常灵活，此模型的灵活性还允许您去创建混合环境。
请注意，在此结构中，混合环境之外的中间CA只能信任混合环境中的根CA和中间CA，信任连接到混合环境中任何中间CA所有的根CA.
D.网格信任模型（Mesh Trust Model）：
当您想要实现具有交叉认证检查的分层信任模型或根CA的网络时，网格信任模型是您的最佳选择。在其他景点中，网格模型使用多路径和多根CA迁移桥结构的概念。
每个根CA中的认证都在所有Root CA，中间CA和叶CA以及连接到每个CA链的所有最终用户中获得授权。