通信过程
网上常见说https通信原理大致是以下几步：
- 客户端发送设备支持的tls协议，加密套件给服务端；
- 服务端接受到信息，返回tls协议、确定使用的加密套件给客户端；
- 服务端发送数字证书给客户端，数字证书里包含服务端的公钥，用CA的公钥加密的;
- 客户端接受到数字证书，判断证书是否过期，使用者是否是对应的域名，然后用CA的私钥去解密，得到服务端的公钥；
- 客户端用公钥结合公共参数生成了对称秘钥发送给服务端，其中包括公共参数，服务端用私钥加密和公共参数再去生成和客户端一模一样的对称秘钥，保证两边的秘钥是对称的；
- 客户端和服务端发送数据，接收数据都使用对称秘钥加解密数据。
简单概括，用非对称秘钥生成对称秘钥进行通信；通信过程中还会涉及到会用到一些随机数，类似TCP标识的原理去保证HTTPS是可行的，这里简单概括。
这里有几个问题：
什么是公钥私钥？
用RSA生成的，公钥可以解对应私钥加密的东西，私钥可以解对应公钥加密的东西；私钥服务器自己保存，公钥发送给使用方；
为什么不直接使用公钥和私钥去通信，而是要加入CA加密
- RSA的计算过程比较耗时。
- 如果服务器直接发公钥，存在被篡改的风险。
为什么需要CA私钥加密去服务器公钥
同上第二点
如何获取CA的公钥去解密数字证书，CA下发公钥不是也会被篡改吗
CA公钥会内置在我们的电脑、手机等设备中，不存在去请求获取公钥所以不会被篡改。但是如果非法重装用了有病毒的系统，可能会导致CA公钥被篡改。
内置在设备里的CA证书会不会过期
会，一般过期时间超过十年，设备更新系统的时候也有可能会更新CA证书；
如何保障数字证书是有效的
设备里会有N个层级的证书，形成证书链，每下一级证书都是用上一级的证书用私钥加密的，然后下发给设备，在设备中会用上一级的公钥去解密下一级的证书中的加密串，得出下一级的公钥；比如当用户接收到c.b.a.com的数字证书时，会用b.a.com的证书里的公钥去解密c.b.a.com的证书解密，b.a.com的证书里的公钥会用a.com的公钥去解密，依次到根证书。如果过程中解不开，证明证书是有问题的。
怎么确定加密套件
客户端提供支持的套件的信息
服务端从中选择加密的套件，这里用的是RSA,SHA256加密算法
抓包数字证书
了解完通信原理，笔者会有个疑惑，都说服务端会下发数字证书给客户端，那到底是怎么下发的呢？没有观察过总觉得自己不够理解https的通信过程。
试过在chrome上将域名对应的证书删掉，但是重新访问对应域名时，在network面板上并没有看到服务端会返回证书相关的资源，访问域名成功的同时，通过chrome管理面板确实看到证书已经是下载下来了。只能说自己抓包的手段不对，怀疑chrome只能抓应用层请求(http)。
带着这样的怀疑尝试用 wireshark 去抓包。wireshark 与 chrome，whitsle等抓包工具不同，wireshark是基于网卡去抓包的。结论是数字证书确实是服务端下发给客户端的，可以通过wireshark抓包发现。
先配置过滤规则：
ip.src eq <目标ip> or ip.dst == <目标ip>
请求源ip和目的地ip都是服务器地址，目的是想看下在https下，是如何通信的。
配置好过滤规则之后，运行就可以看到抓包界面了
https 通信也会有握手流程，比如上图中的，client hello -> server hello -> Certificate, server key Exchange, Server Hello Done -> Client Key Exchange ….. – > Application Data
其中 Certificate, server key Exchange, Server Hello Done 就是证书返回的时机了，打开Certificate通过信息面板可以看到tls的版本，加密方式等等。
将字节流保存为证书.cer格式，再打开，就能看到我们的证书信息了。
参考
原文链接：https://juejin.cn/post/7317141855517327360 作者：Sthenia
