前言：我这里记录了关于CA证书->https单向认证->抓包工具在https抓包原理->https双向认证
CA证书
先来了解下关于CA证书
证书是用来证明公钥拥有者身份的凭证。
CA证书的由来
CA证书一般由证书认证机构（CA）签发，过程：
1、申请者自己通过非对称加密算法（RSA） 生成对应的公钥和私钥，然后把需要的申请信息（国家，域名等）连同公钥（就是RSA生成的公钥）发送给 证书认证机构（CA）
2、证书认证机构（CA）确认无误后通过消息摘要算法（MD5，SHA) 加密申请的CA证书中的信息，加密完的就叫信息摘要，然后把信息摘要用CA的私钥（申请的RSA私钥） 进行加密，加密完的数据就是签名。
对于如上申请的证书中包含如下的内容：
1）RSA公钥
2）证书拥有者身份信息
3）数字证书认证机构（发行者）信息
4）发行者对这份文件的数字签名及使用的算法
5）证书的有效期
总结：CA证书包含以下信息：申请者公钥、信息摘要（申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文），同时包含一个签名sign（对信息摘要用RSA私钥加密的一段sign值）。
https单向认证
网上的一张图，我自己觉得好理解就拿过来放上去了
1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即CA的公钥。
3、客户端使用服务端返回的信息验证服务器的合法性，包括：
* 证书是否过期（这个可能就是平常访问浏览器有红色的提示的原因）
* 发型服务器证书的CA是否可靠（这个可能就是平常访问浏览器有红色的提示的原因）
* 返回的公钥是否能正确解开返回证书中的数字签名
* 服务器证书上的域名是否和服务器的实际域名相匹配
* 验证通过后，将继续进行通信，否则，终止通信
4、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择。
5、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
6、服务器将选择好的加密方案通过明文方式返回给客户端。
7、客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，这个随机码则用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务端。
8、服务器收到客户端返回的加密信息后，使用CA的私钥进行解密，获取对称加密密钥。 在接下来的会话中，服务器和客户端将会使用该对称加密密钥进行对称加密，保证通信过程中信息的安全。
个人理解：单向认证在认证方面，只有客户端对服务端的证书进行了验证，验证了这个SSL证书是否是可信的，而服务端并没有对客户端的相关信息进行验证，这就导致了下面抓包工具在https中进行抓包！
抓包工具在https抓包原理
1、客户端向服务器发起HTTPS请求。
2、Charles拦截客户端的请求，伪装成客户端向服务器进行请求。
3、服务器向“客户端”（实际上是Charles）返回服务器的CA证书。
4、Charles拦截服务器的响应，获取服务器证书公钥，然后自己制作一张证书，将服务器证书替换后发送给客户端。（这一步，Charles拿到了服务器证书的公钥）。
5、客户端接收到“服务器”（实际上是Charles）的证书后，生成一个对称密钥，用Charles的公钥加密，发送给“服务器”（Charles）。
6、Charles拦截客户端的响应，用自己Charles的私钥解密对称密钥，然后用服务器证书公钥加密，发送给服务器。（这一步，Charles拿到了对称密钥）。
7、服务器用自己的私钥解密对称密钥，向“客户端”（Charles）发送响应。
8、Charles拦截服务器的响应，替换成自己的证书后发送给客户端。
至此，连接建立，Charles拿到了服务器证书的公钥 和 客户端与服务器协商的对称密钥，之后就可以解密或者修改加密的报文了。
HTTPS抓包的原理还是挺简单的，简单来说，就是Charles作为"中间人代理"，拿到了 服务器证书公钥和HTTPS连接的对称密钥，前提是客户端选择信任并安装Charles的CA证书，否则客户端就会"报警"并中止连接。这样看来，HTTPS还是很安全的。
这里就拿Charles如何实现https的抓包机制，重点在红色的标记字体中，红色的标记字体就体现在我们平常所讲的搭建抓包的时候需要在手机中导入抓包工具提供的CA证书，原因也就是这个！
可以看出这个流程，是符合https单向认证的流程验证，其实这个也就是https单向认证，唯一的不同就是多了一个中间人！
接下来我们继续来看下双向认证
https双向认证
1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书
3、客户端使用服务端返回的信息验证服务器的合法性，验证通过后，将继续进行通信，否则，终止通信，其中包括：
* 证书是否过期
* 发型服务器证书的CA是否可靠
* 返回的公钥是否能正确解开返回证书中的数字签名
* 服务器证书上的域名是否和服务器的实际域名相匹配
4、服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端（在APP中一般都是类似client.p12的文件等等的）
5、验证客户端的证书，通过验证后，会获得客户端的公钥
6、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择
7、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式
8、服务端将加密方案通过使用之前获取到的公钥进行加密，返回给客户端
9、客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端
10、服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。
个人理解：
1、双向认证比起单项认证来说，客户端和服务端之间相互都有认证，客户端需要服务端证书的公钥，服务端需要客户端证书的公钥，双方拿到了之后会通过对通信的加密方式进行加密这种方法来进行互相认证，最后客户端再随机生成随机码进行对称加密的验证
2、单向和双向认证在通信中都是基于对称加密来实现