引入证书:
当服务器使用HTTPS之前都会申请一份证书，证书是为了证明服务端公钥的权威性，服务器向浏览器传输证书，浏览器再从证书里获取公钥，
证书=明文数据+签名。
如何理解CA签发证书的过程
a.CA会有自己的公钥 和 私钥（CA独有） CA CA*
b.CA会公布CA的公钥 我们的客户端必须内置CA公钥
c.我们的浏览器只认CA的公钥，也就意味着只有CA有着签发证书的权利
首先服务端向CA提交自己的企业信息申请认证证书，CA审查后，对企业的明文信息用哈希或其他的方法形成数据指纹，CA用自己的私钥对数据指纹加密形成签名，这个签名由于只有CA拥有私钥，所以无法生成第二个签名。CA再将签名和明文信息放在一起，形成证书。再签发给服务端,
证书里的明文，中间人不是也可以去获获取篡改？
思考一下，假设我们是中间人，我们肯定是像方案四一样，再客户端得到服务端的公钥之前就把服务端的公钥改成自己的公钥，如果不在客户端得到之前改，那么客户端一得到服务端的公钥 S ，就传递S+P（客户端公钥）给服务端，此时中间人再怎么样也得不到客户端的公钥P了，此后服务端与客户端开心的用P加密用P解密，也就无懈可击了。所以重点是中间人是要去篡改服务端公钥，换成自己的公钥
a.CA会有自己的公钥 和 私钥（CA独有） CA CA*
b.我们的客户端必须内置CA公钥
c.我们的浏览器只认CA的公钥，也就意味着只有CA有着签发证书的权利
中间人假设去改公钥，但是客户端对照一下数据指纹，发现明文数据形成的数据指纹与签名解密出的数据指纹不一样，就会发现内容被改了，
那如果去改签名再去改数据，此时，签名被改了，当客户端用CA的公钥对签名进行解密，发型客户端根本无法解密，自然也就发现签名被改了
那改证书呢，那把证书向CA申请证书再换成自己的证书，一是自己企业信息暴漏，二是在明文信息中有域名，当浏览器识别到中间人证书域名跟自己请求访问服务器的域名不一样，也就发现证书被换了。
所以中间人想篡改服务端的公钥，就不能得逞了。
