https、包括CA证书是为了解决http明文传输不安全的问题，提出http over ssl/tls的方案。
接下来笔者按照自己的理解，讲一下这个方案可能的推理形成的过程。有不当之处欢迎指正，永远怀着谦卑的心。
公钥-私钥 非对称加密
首先容易想到的是方案一，使用非对称开放公钥密钥体系：
1、客户端向服务端请求正式数据之前，先请求公钥，服务端自己保留私钥。
2、客户端用公钥加密正式数据，传给服务端，服务端用私钥解密。
漏洞与劫持
上面的方案漏洞在于，一旦客户端与服务端之间被安插了一个proxy，这个恶意代理收到客户端的公钥请求，然后代替客户端向服务端拿到了真正的公钥，但却把自己的假公钥返回给了客户端，之后客户端用假公钥加密的数据都将会被代理解密获取！更可怕的是，在这个过程中代理由于获得了服务端公钥，仍然可以当作没事儿一样假扮客户端跟服务端进行通信，客户端和服务端完全意识不到双方的加密通信已经被窃听。这就是传说中的劫持。
而且，除去安全漏洞不说，上述方案一直在用非对称加密方式进行通信，性能也不太好。
解决这个漏洞 CA证书
回过头来看一下，上面的方案的问题在于：客户端缺少一种能够识别获得的公钥到底是不是服务端真正公钥的手段！
由此，我们引入方案二：CA证书。
1、客户端先安装权威机构也就是CA颁布的根证书（也就是CA的公钥）：任何使用本方案的服务端会把自己的公钥事先提供给CA，CA使用自己的私钥对公钥加密后生成所谓的“CA证书”，而CA根证书则可以验证服务器公钥的真实性。
2、客户端向服务端请求CA证书（也就是经过CA私钥加密后的服务端公钥），顺便告诉服务端自己支持那些对称加密算法。
3、客户端收到CA证书之后，先识别一下真实性，然后本地生成一个随机密码、并用已经验证了真实性的服务端公钥对这个随机密码进行加密。
4、服务端对收到的随机密码包进行解密，拿到真正的随机密码。
5、到这里，双方都获得了一个可以用于对称加密验证的随机密码，之后的流程，就是客户端与服务端使用这个随机密码进行对称加密通信的过程了。
总结一下
兜了这么大圈子，其实一开始使用对称加密通信也是OK，关键在于如何可靠的让双方都知道对称加密算法中的密钥。
当面把密钥定下来、双方都知道了，这肯定可以，但这太扯淡和原始了。
于是发明了非对称开放公钥体系：把公钥让所有人都知道，然后你们尽管密文发来，服务端有办法验证这密文是不是用自己开放出去的公钥加密的。
但是又有上面说的劫持的那种情况，于是问题变成了怎么想办法安全的传递密钥，只要密钥是安全传递了，那之后用对称加密其实也行了。于是引入了CA证书。
更多请参考 SSL/TLS协议运行机制的概述 - 阮一峰的网络日志 (ruanyifeng.com) 阮一峰老师讲解的非常深入浅出
