证书链的终极版

admin管理员组

文章数量:1564644

1证书链的组成

       如图所示Win10浏览器上百度的证书链，由一个根证书，中间证书（一个或多个），用户证书等组成一条完整证书信任链。只有当整个证书信任链上的各个证书都有效时，浏览器才会认定当前颁发给用户的证书是有效和受信任的。而证书链文件是指除了用户证书以外中间证书和根证书组成的证书文件称之为证书链文件。证书链文件是证书部署和验证证书是否可信环节中最重要的组成部分。

 根证书

       是受信任CA证书颁发机构给自己颁发的证书,是信任链的起始点。浏览器判断根证书是否受信任主要是通过检索浏览器的根证书库可信任列表里是否存在。根证书内置在浏览器或操作系统中。如下图是我的根证书。

       如果存在浏览器就会信任该根证书。目前有的浏览器会自建根证书库，例如火狐浏览器，有的浏览器会使用其他浏览器的根证书库或者调用操作系统的根证书库，例如谷歌浏览器。根证书信息查看可以通过点击根证书后查看证书信息后显示根证书的颁发者以及有效期等信息。

 

中间证书

       中间证书是根证书颁发机构CA对中间证书颁发机构的公钥进行数字签名得到的证书。中间证书的作用主要是为了保护根证书。因为如果直接采用根证书签发证书，一旦发生根证书泄露，将造成极大的安全问题。中间证书可以不止一个，目前我们经常看到有两级中间证书的，原则上中间证书层数越多，根证书越安全。但是一般情况下最多也不超过2级。

用户证书

        用户证书是由中间证书CA签发给用户的证书。用户证书由中间证书证明可信。用户证书是浏览器上实际体现和使用的证书。用户证书可以通过点击小锁后查看到该证书颁发给哪个域名或者ip，证书有效期，颁发机构等信息。如下图所示：

 

2.查看根证书

在自己Win10上查看根证书：

点击“Win+R”,打开运行对话框。

输入“certmgr.msc”命令,然后点击回车。

选择“受信任的根证书颁发机构”，即可看到。

3.证书链的验证

       从终端（用户或浏览器）证书开始，然后是一系列中间CA证书，最后是根证书。检查是用证书链中的下一个证书的公钥来验证当前证书的签名，一直检查到证书链的尾端（根证书），如果所有验证都成功通过，那这个证书就是可信的。在验证根证书时，客户端会根据证书链中的最后一个非根证书在本地的可信任证书存储区域搜寻匹配的根证书，只有本地可信任证书存储区域中包含的根证书，才能通过验证。

       看到每张证书中都有签名值，以及上一级证书的公钥用来验证下一级证书的签名值，可以看出，验证信任链的方式用的是数字签名技术。证书签名方使用自己的私钥对证书进行签名，得到签名值，然后把使用的签名算法和签名值一同放到证书中去，验证方使用签名方的公钥验证签名值，如果验证成功，表明该证书是由签名方签发的。下面来看看证书校验方，也就是浏览器校验证书链的过程，主要是校验中间证书和服务器实体证书的签名值是否正确。

3.1获取证书链

       当浏览器访问一个HTTPS网站时，进行身份验证，由服务器发送自己的不包含根证书的完整证书链给浏览器，浏览器首先从服务器实体证书开始验证，查看该域名是不是在证书使用者可选名称扩展SAN扩展中包含的域名，如果包含，验证域名成功，接着是证书的有效期验证，扩展验证，校验服务器实体证书中的服务器公钥，通过查看密钥用法扩展，看这个服务器公钥是否用来进行密钥协商和数字签名。

       接下来，校验方通过服务器证书中的CA密钥标识符来获取上一级的中间证书文件，开始中间证书的校验。和服务器证书一样，每一个扩展都由一个critical属性，要验证这个属性的值必须为true，接着进行日期验证，密钥用法扩展。中间证书的公钥除了包含数字签名用法外，还要包括Certificate Sign签名证书用途，CRL Sign证书过期和吊销签署用途。最后校验basic constraints基础约束扩展，检验中间证书是否被允许签发证书。

3.2迭代验证

       身份验证方（浏览器），在身份验证时除了验证服务器实体证书，还要验证整条信任链，保证从服务器实体证书开始，服务器证书的签发者是它的上一级中间证书的使用者，中间证书的签发者是它的上一级根证书的使用者。校验信任链的方式是迭代签名验证，使用数字签名技术。从服务器实体证书开始，获取其上一级中间证书的公钥来验证服务器实体证书的签名值，接着再从中间证书的上一级根证书获取的公钥来验证中间证书的签名值，一直迭代下去，由于除根证书外，其他级证书的签发者是其上一级证书的使用者，到达根证书后，根证书的签发者和使用者都是它自己，所以浏览器在进行迭代验证过程中，发现某一证书的签发者和使用者都是自己后，表明找到了根证书，最后验证跟证书时，使用的就是自己的公钥验证自己的签名值，完整整个证书链的验证。

3.3信任锚

       信任锚也就是信任的起点，对应的就是根证书，因为身份校验方浏览器集成了权威CA机构的根证书，即信任了根证书，也就是信任了由根证书签发的其他证书。对于机构签署的根证书，浏览器内置；对于自签证书，需要手工导入。

下图为自己Win10中集成的根证书。

 

证书验证参考：证书链-证书校验_大力海棠的博客-CSDN博客_证书链验证

 

4.SSL/TLS 协议基本流程：

客户端向服务器索要并验证服务器的公钥。

双⽅协商⽣产「会话秘钥」。

双⽅采⽤「会话秘钥」进⾏加密通信。

前两步也就是 SSL/TLS 的建⽴过程，也就是握⼿阶段。

SSL/TLS 协议建⽴的详细流程

ClientHello

      ⾸先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。

在这⼀步，客户端主要向服务器发送以下信息：

（1）客户端⽀持的 SSL/TLS 协议版本，如 TLS 1.2 版本。

（2）客户端⽣产的随机数（ Client Random ），后⾯⽤于⽣产「会话秘钥」。

（3）客户端⽀持的密码套件列表，如 RSA 加密算法。

SeverHello

      服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello 。服务器回应的内容有如下内容：

（1）确认 SSL/ TLS 协议版本，如果浏览器不⽀持，则关闭加密通信。

（2）服务器⽣产的随机数（ Server Random ），后⾯⽤于⽣产「会话秘钥」。

（3）确认的密码套件列表，如 RSA 加密算法。

（4）服务器的数字证书。

客户端回应

       客户端收到服务器的回应之后，⾸先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。

    如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使⽤它加密报⽂，向服务器发送如下信息：

（1）⼀个随机数（ pre-master key ）。该随机数会被服务器公钥加密。

（2）加密通信算法改变通知，表示随后的信息都将⽤「会话秘钥」加密通信。

（3）客户端握⼿结束通知，表示客户端的握⼿阶段已经结束。这⼀项同时把之前所有内容的发⽣的数据做个摘要，⽤来供服务端校验。

      上⾯第⼀项的随机数是整个握⼿阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就⽤双⽅协商的加密算法，各⾃⽣成本次通信的「会话秘钥」。

服务器的最后回应

       服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发⽣最后的信息：

（1）加密通信算法改变通知，表示随后的信息都将⽤「会话秘钥」加密通信。

（2）服务器握⼿结束通知，表示服务器的握⼿阶段已经结束。这⼀项同时把之前所有内容的发⽣的数据做个摘要，⽤来供客户端校验。

       ⾄此，整个 SSL/TLS 的握⼿阶段全部结束。接下来，客户端与服务器进⼊加密通信，就完全是使⽤普通的 HTTP协议，只不过⽤「会话秘钥」加密内容。

SSL协议参考：HTTPS的连接建立过程_lsz冲呀的博客-CSDN博客

5.国内https证书申请步骤

1、生成证书请求文件CSR

用户进行https证书申请的第一步就是要生成CSR证书请求文件，系统会产生2个密钥，一个是公钥就是这个CSR文件，另外一个是私钥，存放在服务器上。要生成CSR文件，站长可以参考WEB SERVER的文档，一般APACHE等，使用OPENSSL命令行来生成KEY+CSR2个文件，Tomcat，JBoss，Resin等使用KEYTOOL来生成JKS和CSR文件，IIS通过向导建立一个挂起的请求和一个CSR文件。

2、将CSR提交给CA机构认证

CA机构一般有2种认证方式：

(1)域名认证，一般通过对管理员邮箱认证的方式，这种方式认证速度快，但是签发的证书中没有企业的名称，只显示网站域名，也就是我们经常说的域名型https证书。当前流行的沃通免费https证书也是属于域名型https证书。

(2)企业文档认证，需要提供企业的营业执照。国外https证书申请CA认证一般需要1-5个工作日，国内比如沃通CA只需要一小时之内，紧急时5分钟，效率比国外https证书申请高很多。

同时认证以上2种方式的证书，叫EV https证书，EV https证书可以使浏览器地址栏变成绿色，所以认证也最严格。EV https证书多应用于金融、电商、证券等对信息安全保护要求较高的领域。

3、获取https证书并安装

在收到CA机构签发的https证书后，将https证书部署到服务器上，一般APACHE文件直接将KEY+CER复制到文件上，然后修改HTTPD.CONF文件;TOMCAT等需要将CA签发的证书CER文件导入JKS文件后，复制到服务器，然后修改SERVER.XML;IIS需要处理挂起的请求，将CER文件导入。

国内https证书申请参考：怎么申请https证书认证_申请https安全证书步骤 - 沃通ssl证书认证

6. 证书的签发过程：

1. 服务方 S 向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证；

2. CA 通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等；

3. 如信息审核通过，CA 会向申请者签发认证文件-证书。

证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；

签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名；

1. 客户端 C 向服务器 S 发出请求时，S 返回证书文件；

2. 客户端 C 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法；

3. 客户端然后验证证书相关的域名信息、有效时间等信息；

4. 客户端会内置信任 CA 的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA 的证书，证书也会被判定非法。

在这个过程注意几点：

a.申请证书不需要提供私钥，确保私钥永远只能服务器掌握；

b.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名；

c.内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书；

d.证书=公钥+申请者与颁发者信息+签名；

https的通信过程

服务端需要认证的通信过程

1. 客户端发送请求到服务器端

2. 服务器端返回证书和公开密钥，公开密钥作为证书的一部分而存在

3. 客户端验证证书和公开密钥的有效性，如果有效，则生成共享密钥并使用公开密钥加密发送到服务器端

4. 服务器端使用私有密钥解密数据，并使用收到的共享密钥加密数据，发送到客户端

5. 客户端使用共享密钥解密数据

6. SSL加密建立………

浏览器CA认证流程

1. 客户端向一个需要https访问的网站发起请求。

2. 服务器将证书发送给客户端进行校验。证书里面包含了其公钥。这里要特别说一下客户端到底 如何来校验对方发过来的数字证书是否有效。

首先在本地电脑寻找是否有这个服务器证书上的ca机构的根证书。如果有继续下一步，如果没有弹出警告。使用ca机构根证书的公钥对服务器证书的指纹和指纹算法进行解密。 得到指纹算法之后，拿着这个指纹算法对服务器证书的摘要进行计算得到指纹。将计算出的指纹和从服务器证书中解密出的指纹对比看是否一样如果一样则通过认证。

1. 校验成功之后，客户端会生成一个随机串然后使用服务器证书的公钥进行加密之后发送给服务器。

2. 服务器通过使用自己的私钥解密得到这个随机值。

3. 服务器从此开始使用这个随机值进行对称加密开始和客户端进行通信。

4. 客户端拿到值用对称加密方式 使用随机值进行解密。

为什么不一直使用非对称进行加密，而是在类似握手之后开始使用对称加密算法进行https通信：

非对称加密的消耗和所需的计算以及时间远比对称加密消耗要大，所以在握手和认证之后，服务器和客户端就开始按照约定的随机串，对后续的数据传输进行加密。

特点：

1. 非对称加密相比对称加密更加安全

2. 非对称加密算法对加密内容的长度有限制

3. CA数字证书作用之一是公钥分发

4. 数字签名的签发过程是私钥加密，公钥解密

证书签发参考：浏览器获取CA认证流程_慢慢的燃烧的博客-CSDN博客_浏览器的ca证书

7.证书链的特点与管理

1.证书链特点：   

    a.同一本服务器证书可能存在多条合法的证书链。

    因为证书的生成和验证基础是公钥和私钥对，如果采用相同的公钥和私钥生成不同的中间证书，针对被签发者而言，该签发机构都是合法的 CA，不同的是中间证书的签发机构不同;

    b.不同证书链的层级不一定相同，可能二级、三级或四级证书链。

    中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构，所以证书链层级不一定相同。

2.证书吊销

    CA机构能够签发证书，同样也存在机制宣布以往签发的证书无效。证书使用者不合法，CA 需要废弃该证书;或者私钥丢失，使用者申请让证书无效。主要存在两类机制：CRL 与 OCSP。

    a.CRL

    Certificate Revocation List, 证书吊销列表(什么是证书吊销列表(CRL)？吊销列表起什么作用)，一个单独的文件。该文件包含了 CA 已经吊销的证书***(唯一)与吊销日期，同时该文件包含生效日期并通知下次更新该文件的时间，当然该文件必然包含 CA 私钥的签名以验证文件的合法性。

证书中一般会包含一个 URL 地址 CRL Distribution Point，通知使用者去哪里下载对应的 CRL 以校验证书是否吊销。该吊销方式的优点是不需要频繁更新，但是不能及时吊销证书，因为 CRL 更新时间一般是几天，这期间可能已经造成了极大损失。

    b.OCSP

Online Certificate Status Protocol, 证书状态在线查询协议，一个实时查询证书是否吊销的方式。请求者发送证书的信息并请求查询，服务器返回正常、吊销或未知中的任何一个状态。证书中一般也会包含一个 OCSP 的 URL 地址，要求查询服务器具有良好的性能。部分 CA 或大部分的自签 CA (根证书)都是未提供 CRL 或 OCSP 地址的，对于吊销证书会是一件非常麻烦的事情。

证书链特点与管理参考：HTTPS协议详解(三)：PKI 体系 - 程序员大本营

8.证书链作用

通常浏览器和操作系统中集成了CA的公钥信息。客户端会内置信任 CA 的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA 的证书，证书也会被判定非法。

  a.减少根证书结构的管理工作量，可以更高效的进行证书的审核与签发;

  b.根证书一般内置在客户端中，私钥一般离线存储，一旦私钥泄露，则吊销过程非常困难，无法及时补救;

  c.中间证书结构的私钥泄露，则可以快速在线吊销，并重新为用户签发新的证书;

  d.证书链四级以内一般不会对 HTTPS 的性能造成明显影响。

最后一个问题，为什么需要证书链这么麻烦的流程？Root CA为什么不直接颁发证书，而是要搞那么多中间层级呢？

为了确保根证书的绝对安全性，将根证书隔离地越严格越好，不然根证书如果失守了，那么整个信任链都会有问题。

本文标签： 证书终极版