最近了解了一些https的加密解密过程，觉得看完之后感觉好乱，然后自己画了个流程，从请求证书开始一直到与服务器交互完毕：
请求证书部分：
文字流程：
1.客户端A向CA证书颁发机构请求服务端B的证书；
2.CA收到请求，开始做的事情：以B的数字证书生成Hash并用自己的私钥加密此Hash，得到数字签名；
3.CA向客户端下发两样：B的数字证书（私钥加密）和此证书的数字签名；
4.客户端A收到反馈，以CA的公钥（注1）解密数字签名得到待比对Hash值1，同时对B的数字证书进行一次Hash运算得到Hash值2；
5.对比两个Hash值，一致则说明此证书真实完整，得到数字证书，同时得到公钥（注2）;
解释注解：
1.CA的公钥为什么可信，它是怎么来的？如果仔细研究你就会发现无论怎么加密只要开始数据通信都会产生一个鸡生蛋蛋生鸡的悖论：即最外层的密钥是哪来的？CA的公钥是预装在操作系统里的，你可能会说我凭什么信任这个操作系统？他也会被攻击篡改啊？是的没错，但对于信任的话真的不好解释，比如如果不信任微软的话那就别用了吧，至于篡改。。。这个肯定是存在的，每一个CA都会沿着传递链去找上一个CA一直能找到根CA，如果被篡改的话理论上验证时会出问题，好吧就算没有被发现，那就真的没什么办法了。最经典的例子就是12306网站，之前浏览器一直提示网站证书不被信任，因为12306网站的根证书没有被内置在浏览器里。
2.公钥和数字证书的关系，简单地说数字证书就是经过CA认证过的公钥，大家都可以有自己的公钥和私钥，但是只有被CA认证的才是数字证书；
和服务器通讯部分，这个比较简单：
文字流程：
1.客户端A自己生成一对公钥私钥，私钥自己留下，用B的公钥加密数据和自己的公钥，向服务器B发送请求数据；
2.服务器B收到请求，用私钥解密A的请求，并用A的公钥加密要发送的数据；
3.服务器B向A发送两样信息：加密数据和数字签名；
4.客户端A收到信息，验证数字签名，有效则用私钥解密数据；
这段比较简单，很好理解。
以上是我对HTTPS加密解密通讯过程的理解，有不对的地方欢迎交流。
补：
1.从CA处获得服务器B的公钥；
2.给予服务器自己的公钥；
3.数据加密签名；
