写在最前面，如果只是想回顾一下看这个图就行：

一、基础知识

对称与非对称加密

HTTPS之所以安全就是因为加持了SSL这个外挂来对传输的数据进行加密，那么具体的加密方法又是什么呢？

请听我娓娓道来。先看下面两个概念：

• 对称加密
• 非对称加密

你知道上面两个概念是什么意思么？😳

🤣OK，不管你懂不懂，我先用我的方式来给你解释下：

亲，你作过弊么？😑不要告诉我在你漫长的学生生涯里你没作过弊(那你的学生生涯得多枯燥)，作弊我们常用的方法是啥？(说把答案写在胳膊大腿纸条上的同学请你出去，谢谢🙂)当然是加密了！比如我出于人道主义，想要帮助小明同学作弊，首先考试前我们会约定好一个暗号来传递选择题的答案，摸头发——A，摸耳朵——B，咳嗽——C，跺脚——D，于是一个加密方法就诞生了，这个加密方法只有我和小明知道，老师虽然看我抓耳挠腮但他顶多把我当成神经病，并没有直接证据说我作弊。好，这种我和小明知道，别人不知道的加密方法就是一种对称加密算法,对称加密算法也是我们日常最常见的加密算法。这种算法🔑只有一把，加密解密都用同一把钥匙，一旦🔑泄露就全玩完了。

随时时代的进步，人们发现实际上加密和解密不用同一把🔑也是可以的，只要加密和解密的两把🔑存在某种关系就行了。

于是，层出不穷的非对称加密算法就被研究了出来，那么它基于什么样的道理呢？请严格记住下面这句话：

将a和b相乘得出乘积c很容易，但要是想要通过乘积c推导出a和b极难。即对一个大数进行因式分解极难

听不懂因式分解的童鞋先去面壁5分钟，这么多年数学白学了？甩给你维基百科链接，自行补课🙂：因式分解

好的，我们继续，非对称加密算法就多了两个概念——公钥c和私钥b。

用法如下：公钥加密的密文只能用私钥解密，私钥加密的密文只能用公钥解密。

公钥我们可以随便公开，因为别人知道了公钥毫无用处，经过公钥加密后的密文只能通过私钥来解密。而想要通过公钥推导出a和b极难。但很明显的是，使用非对称加密效率不如对称加密，因为非对称加密需要有计算两个密钥的过程。

而SSL加密，正是采用了基于RSA算法的非对称加密算法；

⚠️注意：SSL加密的本质，或者说解决的主要问题是，解决在通信过程中的不安全问题：截取、窃听等

所以在设计时，要考虑连路上，是否存在窃听、截取、干扰的可能

二、传统方案

由上可知，加密过程没问题，而关键问题是，在公钥发送的过程，当服务端将自己的公钥发给对端时，无法证明自己的身份。因此，针对上述流程，核心要解决的问题就是，如何证明Server发出的公钥就是他自己的，但自己肯定无法证明自己，需要一个第三方来证明自己

解决思路：双方找到一个可信的第三方，有第三方确认Server的公钥是他的

所以：有两个问题需要解决
 1、第三方如何证明（用什么方式证明）这个证书就是Server的？

  2、Client如何确认第三方的“证词”？

具体的：

在实际中，这个第三方，就是CA机构，即一个Server和Client都可信任的机构

那么，如何解决上述的两个问题：

1、CA用什么东西去证明Server？

解决：数字证书，CA通过数字证书来证明Sever的公钥就是他自己的。

那么，数字证书是如何证明的？具体概念和原理是啥？

数字证书：数字证书就是互联网通讯中标志通讯各方身份信息的一串数字，提供了一种在Internet上验证通信实体身份的方式，数字证书不是数字身份证，而是身份认证机构盖在数字身份证上的一个章或印（或者说加在数字身份证上的一个签名）。

通过上图，已经很好理解数字证书的内容了。对应到开发中，在我们自己给自己签名时候，首先要把自己当成一个ca机构，那么我们使用命令：

openssl req -new -x509 -days 36500 -extensions v3_ca -keyout ca.key -out ca.crt

具体：ca.key就是CA机构的私钥（为啥有这个，下面说），ca.crt(证书，可以理解为CA的公钥，用来证明自己的)

通过上面，我们也只是知道了CA证书的大致原理和使用，但是还没说明白如何证明的？

答：我们回到上面的那个流程图中的回传公钥那一步，就是说，当Client收到Server发来的公钥后，根据上面的思路去理解，要找CA去验证，可找CA的过程仿佛又回到了之前的流程，要去和CA链接请求数据，可是万一中间也有截取的，那么去和CA请求数据似乎还需要找一个新的CA，回到了反复循环的过程。

因此，为了跳出这个步骤，就要求我们的操作系统，在出厂时，先预制CA的证书（公钥），也就是说，当你去找CA验证的时候，不用再去网上请求数据，陷入反复循环，而是直接从本地的证书中查询，那这个本地证书就是上面说到的ca.crt.

Windows 查看方法：win+r —– 输入mmc 即可查看

centos路径：/etc/pki/tls/certs/ca-bundle.crt

ubuntu路径：/etc/ssl/certs/ca-certificates.crt 

那说了这么多，也只是明白了，Client客户端可以通过预置的CA证书中的公钥加密信息，来与CA进行可信的通话，但似乎与一开始要解决Server端的公钥可信的问题绕的有点远；因此，这里就要说明，如何利用CA预置的证书去解决这个问题。

三、加密后的具体流程

-1、前置条件，客户端已经预置CA的证书，证书中包含CA的公钥，这个公钥可以解密—–CA机构用手里的私钥加密的信息。

0、前置条件，Server 服务端位了让用户通过CA信任自己，因此，必须要向CA机构提交自己的证明文件，类比那个证书，就是写证书的时候要提交Server的一些个人信息；具体的，比如Server的公钥信息、hash算法等一系列东西，而在实际中，这些东西就像一个证明材料，我们理解为一个后缀为.csr的文件

openssl req -out server.csr -key server.key -new  

1、在Server向CA提交了申请材料后，CA机构就会给Sever签名，可以理解为给Server提交的材料盖一个章，具体就是盖在了Server 的公钥上，但CA好歹也是一个可信的机构，盖一个普通的章显然不行，万一别人拿萝卜刻了怎么办？所以，在这里这个章，就要加密，这个加密分为两部分：

         A）首先，根据Server提交的材料（材料里有Server的公钥，hash算法），生成一个Server提交的HASH算法所产生的HASH值，这个值唯一；具体点，就是CA说：Server提交的东西，我确认了，根据他提交的内容，我得到了一个独一无二的值（理解为证书编码），我们把这个值称为HASH-CA；

        B）接着，光有那个HASH-CA也不行啊，万一别人替换了怎么办，仅此，继续加密，也就是CA会用自己的私钥，将Server提交的材料（Server的公钥、Server的HASH算法）以及CA机构算出的HASH-CA，一同加密；这个就可以理解为，将写了证书编码、盖好章的证书放到一个信封中，并贴好邮票，写上Client凭手中的我CA的公钥可以打开。

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 36500

2、至此，Server就拿到了CA办法给他自己的证书（server.crt），这时，Server在与Client沟通交流时就有了底气。

3、回到一次正常的SSL通信过程（也就是上面说的那个传统方案）：当Client，使用SSL链接Server时候：Client想和Server 安全的对话（发送了请求，获取公钥）；

4、Server在接到Client的请求后，也不再唯唯诺诺，怕Client不相信，而是直接掏出了CA颁发给他的证书（server.crt,就是那个贴了邮票的信封）给了Client

5、Client拿到这个这个证书的时候，哎，一看这是嘛呀？发现信封上面写着，请用CA给你的公钥打开。此时，CA预置在Client中的公钥终于派上了用场；因为是预置了的公钥，就是可信的（黑客要是黑进来，把证书换了，你也没招，但可以定时更新自己的证书）。

6、Client拿着自己的CA给的公钥，先解开了CA加密的内容，也就是打开了信封，终于看到了里面的内容（就是上面的那些字段），但光凭着这一张纸依旧让人不敢相信（万一那个章真的是水萝卜刻的呢？）

7、看到了证书里面的内容后，我们就能得到证书写的东西，有两部分：

        1、Server提交的材料（Server的公钥，这个是我们最想确定的，还有就是Server的HASH算法）

        2、CA机构提供的HASH-CA

8、有了上面的材料，Client变开始确认，CA说的Server的公钥到底可信不可信？因为证书包函了Server的HASH算法，所以，Client根据这个HASH算法也能得到一个唯一的HASH值（证书编号），HASH-Clinet；Client用得到的HASH-Client去对比证书里的HASH-CA发现，两个值相等：说明，CA确认了Server的公钥没有被修改过。

至此，一次SSL加密证书交换的过程也就解析完毕。

（PS：但这样也不安全，为啥？可以暴力激活成功教程公钥和私钥然后篡改，但是！！！激活成功教程的时间比较长——>假设我们设定一个超时时间，超过时间就丢掉，那么在算力没有很强大的时候，这个方式还是很有用的）

最后，补一张图，描述一下过程：

具体流程（加密方案，和一开始的图相同）