数字证书？https？超详细描述https传输过程！

今天药忘吃喽~ 2023-02-25 07:13 17阅读 0赞

### 文章目录 ###

*  写在前面
 *  铺垫性知识
 *  图片展示
 *  具体过程
 *  过程疑问

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FiY251bGw_size_16_color_FFFFFF_t_70]

# 写在前面 #

创作不易，装载还望标注，感谢！(\#.\#)，才疏学浅，有异议或者错误的地方还望大家指正！

**为什么不使用 http 呢？因为有以下安全隐患**

*  通信使用明文，内容可能被监听
    
    互联网世界，是由联通到全世界的网络组成，进行 http 请求一旦经过某一个通信线路，此通信线路上某些网络设备都有可能恶意的对通信的数据进行窥探
 *  不验证通信时对方的身份，因此通信方可以进行伪装
 *  无法验证报文完整与否，所以改了报文也不知道

# 铺垫性知识 #

**https？**

HTTP 通信接口部分采用了了 SSL + TLS 协议

**数字证书？**

数字证书又称为 CA 证书，又称为公钥证书，建立在非对称密钥技术之上，是 CA 机构颁发给服务端的，数字证书包含如下两大部分：

*  服务器的公钥
 *  数字签名

**数字签名？**

数字签名实际上就是加密后的服务器公钥，为什么叫签名呢，因为同现实中的合同一样，这个数字签名就是用来认证识别身份的东西。数字签名如何生成呢？

*  首先将服务端的公钥进行转化，通过数字摘要算法转化成数字指纹
 *  再使用 CA 机构的私钥对数字指纹进行加密，生成数字签名

**数字指纹？**

数字指纹或称为数字摘要，就是将服务端公钥通过数字摘要算法转变成的某个 hash 值

**关于公钥和私钥**

服务端有公钥和私钥，CA 机构也有公钥和私钥，数字证书中被 CA 私钥加密的是服务端的公钥，数字证书中还有未加密明文显示的服务端公钥，服务端公钥本来就是公布出去的，之所以加密服务端公钥是为了后序进行验证合法性。CA 机构的公钥在更早的时候已经植入在用户机器或者用户浏览器中

公钥和私钥是相对而言，公钥是公开的密钥，私钥是不公开的密钥，如果我知道公钥和知道被私钥加密后的数据，也是无法推出私钥是多少的，试想一下如果拿到了 CA 私钥，这将是一件很可怕的事情，因为它可以伪造证书，然后自己随意创建服务端的非对称秘钥，通过 CA 私钥对服务端公钥加密，这样也会被客户浏览器识别为合法的证书！

# 图片展示 #

https 的传输过程大致是如何的呢？我们来看非常具有总结性的图片描述

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FiY251bGw_size_16_color_FFFFFF_t_70 1]

# 具体过程 #

**在客户端浏览器 https 请求服务器之前的一些故事…**

1.  最开始故事是这样的，某龙头企业 mlcrosoft 向 CA 组织申请自己成为 CA 机构
    
    最开始，某一龙头企业向 CA 组织申请自己可以成为受 CA 组织管控的 CA 机构来进行数字证书的分发工作（这样的好处是自己可以给自己签发大量的子证书），CA 组织经过复杂的审核后同意该 CA 机构合规
2.  CA 机构强制系统和浏览器安装自己的证书
    
    新成立后，CA 机构会强迫所有的系统和浏览器安装自己的 CA 机构根证书（根证书中含有 CA 机构的公钥，用于对向 CA 机构申请的数字证书进行解密操作），这些 CA 根证书一般通过系统更新安装在系统中（比如 IE 和 chrome），或者浏览器新版本更新植入浏览器内（比如 FireFox），根证书我们可以在 windows 中搜索“internet 选项”【内容】->【证书】->【受信任的根证书颁发机构】来查看，但是这里会有一个漏洞，需要大家注意：如果 CA 机构直接使用根证书的公钥私钥来对申请通过的数字证书解密加密，当这个 CA 机构被 CA 组织取消资格或者该 CA 机构一旦颁发错了根证书，那就意味着此 CA 机构签发的所有数字证书都会失效，这是一个很麻烦的事，解决思路就是 CA 机构一般不直接通过根证书来签发各个申请厂家的数字证书，而是通过一个中间证书来对各个申请厂家的数字证书进行签发，中间证书又是被根证书的密钥进行加密，中间证书的密钥又可以对各个厂家申请的数字证书进行加密操作，这样的三个角色形成了一个**证书链**，若 CA 机构的根证书被取消了，但是中间证书的存在使得各个厂家申请的数字证书依旧被识别为安全有效。中间证书实际上可以重复多次，也就是说存在中间证书到中间证书到中间证书再到各厂家申请的数字证书的形式。中间证书我们可以在 windows 中搜索“internet 选项”【内容】->【证书】->【中间证书颁发机构】来查看
3.  之后有一大厂向 CA 机构申请数字证书
    
    此刻，某一大厂的服务端生成了自己的公钥和私钥，它开始向 mlcrosoft （CA 机构）申请自己的数字证书
4.  大厂拿自己的公共密钥登录到数字证书认证机构 CA 申请自己的数字证书
    
    这个机构目前几乎全部被欧美掌控，CA 机构不止有一家，而是众多家，这些 CA 机构会分发数字证书，很多国外巨头企业自己也有 CA 机构，比如微软，它就可以做到自签，定期会有 CA 组织统一管理这么多被认可的 CA 机构，对他们签发给每位申请者的每一张数字证书进行审查工作
5.  CA 机构使用自己的密钥对申请厂家服务端的公钥进行数字签名以及颁发数字证书操作，这样各申请厂家就可以拿到了属于自己的数字证书了

**客户端浏览器开始 https 请求服务器的复杂故事…**

1.  客户端浏览器进行 https 访问请求
2.  服务端收到 https 访问请求，会向客户浏览器发送自己的数字证书
    
    发送回来的数字证书中包含了各种信息，包括被证书链中上层 CA 私钥加密后得到的数字签名，还包含服务的端的公钥，以及该证书的上层签发机构是谁
3.  浏览器自己来验证数字证书的可信性
    
    具体的操作过程是，浏览器拿到了服务端发送过来的数字证书之后，通过数字证书中指明的颁发者是谁，在系统或者浏览器的受信任证书中找到这个颁发者证书，并且用这个颁发者证书（上层证书）中暴露的公钥对数字证书中的数字签名进行解密操作，解密之后浏览器就可以拿到数字指纹或者称之为数字摘要，它是一个将服务端公钥通过数字摘要算法转化得到的 hash 值，浏览器如果要验证这个数字证书是合法的，实际就是验证这个数字指纹是匹配的，浏览器怎么验证指纹匹配呢？它会通过数字摘要算法把数字证书中的公钥转为新的数字指纹，然后浏览器拿这个新生成的数字指纹和利用上层 CA 公钥解密之后得到的数字指纹进行匹配，如果匹配的结果是一致的，那就直接说明该证书是没有问题的。
    
    由于存在一整套证书链，服务端返回的数字证书是由存储在浏览器中或者系统中的上层证书所签发的，然后这个上层证书又是由再上一层证书签发的，最上一层就是根证书了，根证书是自己签发自己，用自己的暴露的公钥可以对自己的数字签名解锁，这种层层签发的证书形成了一个有效的证书链，当我们识别出服务端返回的证书是合法的时候，我们会依次向上访问上层证书（一一解密），直到 root 根证书为止，若浏览器最终访问到它信任的根证书的时候，那么浏览器将会把服务端返回的数字证书识别为可信的数字证书，有时候你会发现浏览器会对没有安装中间证书的网站做出不可信的提示，这实际就是完整证书链缺失的后果
4.  浏览器验证数字证书通过后随即生成对称密钥
    
    由于在加密解密的效率上，对称密钥要比非对称密钥快 3 个数量级以上，所以在不断传输数据信息的过程中我们选择使用对称密钥来加密，非对称密钥主要是在最开始判定通信双方的合法性处有用。
5.  浏览器将前面保存下来的数字证书中公钥对自己产生的密钥加密并回传给服务器
    
    我们都知道直接使用对称密钥加密的数据容易被破解，因为加密的锁同时也是解密的钥匙，所以一旦拿到密钥就可以破解数据信息，所以我们决定在最开始验证往数字证书之后，需要保存下数字证书的公钥，然后使用这个公钥对客户浏览器产生的密钥进行加密操作，再回传给服务端，这样就可以保证对称密钥不对外暴露
6.  服务端拿到被自己公钥加密的数据信息，通过自己的私钥进行解密
    
    服务端拿到回传过来的数据，通过自己的私钥进行解密，就可以得到客户端的对称密钥，并且将其进行存储
7.  客户浏览器这个时候才开始正式发送含有\[使用对称密钥加密后的数据信息\]的接口请求
8.  服务端收到请求后进行解密拿到数据信息
    
    服务端收到请求后，通过某种匹配，选出刚才存储的密钥并对数据信息进行解密操作，这样就可以拿到数据明文了！

# 过程疑问 #

1.  为什么 https 不直接使用服务端的公钥对数据信息进行加密，而是使用公钥先对密钥加密，之后再用密钥对数据信息加密的方式呢？
    
    答：我们知道 https 采用的是非对称密钥和对称密钥混合加密机制，若仅仅使用非对称加密，即仅仅使用服务端提供的公钥来加密可行吗，理论上同样也可以，但是不好，其处理速度比对称密钥要慢很多，网上统计是对称加密算法比非对称加密算法快大约1500倍。所以这下就清楚了，在请求服务器的最开始阶段，我们通过非常安全的非对称密钥技术，服务端将公钥交给浏览器（里头涉及数字证书以及公钥进行解密的过程），这一步其实挺慢的，但是好在只用在开头执行一次，之后如果依旧使用这个公钥对数据信息加密和服务器私钥对数据信息解密，这就太慢了，所以后序我们使用更加快速的对称密钥技术，用公钥对密钥加密给服务端，即使中间人截取了数据，由于没有私钥所以也没法对工要加密的数据进行解密，这样就保证了对称密钥的安全性，因此也就可以保证以后传输数据信息使用对称密钥加密不怕被窃取
2.  浏览器 https 请求服务端时，服务端会返回一个公钥，但是我们怎么确定这个公钥就是指定的服务器的公钥，而不是随意的一个公钥呢？
    
    答：实际上服务端返回不是一个公钥，准确的说是一个数字证书，证书中包含如下：
    
     *  服务器的公钥
     *  数字证书认证机构的数字签名
    
    服务器的公钥就是问题中服务器传给浏览器的公钥，还有一个数字签名又是什么呢？数字签名生成过程是如何的呢？
    
     *  转化
        
        服务端公钥通过数字摘要算法先转为数字指纹
     *  加密
        
        使用 CA 的密钥对数字指纹进行加密
    
    当客户端 https 请求服务端时候，服务端会返回一个数字证书给客户浏览器，客户浏览器使用早已内置在浏览器中的 CA 公钥（其实是内置的根证书中有公钥）对数字证书中的数字签名进行解密操作得到数字指纹，然后浏览器再对数字证书中的公钥进行数字摘要算法转为数字指纹，浏览器将解密得到的数字指纹和刚新生成的数字指纹进行比对，如果一致就表示证书合规，所访问的网站是合法的

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FiY251bGw_size_16_color_FFFFFF_t_70]: /images/20230209/0f30bfa34cd647d3b3f98c351f9e65e5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FiY251bGw_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20181204122336858.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FiY251bGw=,size_16,color_FFFFFF,t_70