参考：https://blog.51cto.com/11883699/2160032
上面说的已经很好地，我这里简单做个总结：
在网上我们做数据交互时候一般用的http协议，但是这种方式会使得交互内容明文化，很不安全，后来人们就想讲这个过程加密。
1）对于加密算法有对称加密和得对称加密算法，如果用对称加密算法加密客户端与服务端信息交互，方式：客户端给服务端发请求，服务端给客户端A回复使用对称秘钥A，客户端接收到对称秘钥A后回复知道了，之后客户端A就用对称秘钥A加密与服务端交互信息；同样服务端会给客户端B发送对称秘钥B，于此类推。但是这个过程中存在一个问题：对于这个秘钥协商的过程，是明文的，如果被第三方拦截，之后的操作在这个第三方面前都是明文的了
2） 为了解决1）中秘钥协商过程的明文容易被拦截获取，需要想个办法加密这一过程，于是乎我们可以用非对称秘钥加密算法（私钥加密后的密文，只要是公钥，都可以解密，但是反过来公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人）来处理这一过程，具体方案：客户端A给服务端发送请求，服务端给客户端A发送一个非对称加密算法的公钥，自己留一个私钥，客户端获得这个公钥后，用这个公钥给服务器发送信息（包含对称加密算法，对称秘钥等信息），服务端收到消息解密获得对象消息，并用收到的对称加密算法加密信息给客户端发送收到了，之后就用这个客户端发来的对称加密算法来加密解密两者之间的信息交互。到这里看似已经很完美了，但是这中间还存在交互的过程是明文的且如果被第三方拦截，对于第三方来说还是明文交互了，这个地方就是：客户端问服务端获得非对称秘钥的公钥的过程。假设：如果客户端给服务端发送获取公钥的请求，被第三方拦截，第三方伪装成服务端，给客户端发送一个假公钥发给客户端，同时给真正服务端发送请求获得真正公钥，这样对于第三方来说跟明文交互一样了
3）为了解决2）中客户端与服务端明文交互获取分对称加密算法中的公钥被拦截的问题，这里用到了我们的最终密码武器“SSL证书需要购买和CA证书”保证了客户端获取的公钥是安全的，其中SSL 证书中包含的具体内容有证书的颁发机构、有效期、公钥、证书持有者、签名，通过第三方的校验保证了身份的合法，解决了公钥获取的安全性。具体方式：客户端发送请求给服务端，服务端返回一个SSL包（具体内容有证书的颁发机构、有效期、公钥、证书持有者、签名），客户端的校验过程：
以浏览器为例说明如下整个的校验过程：
（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验
（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发
（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。
（4）如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密
（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比
（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充
（7）此时浏览器就可以读取证书中的公钥，用于后续加密了