本篇文章主要讲述HTTPS协议的工作过程，以及怎么解决公钥交换过程中被替换的问题
HTTPS 协议交互过程
1、客户端发起SSL通信，报文中包含客户端支持的SSL版本，加密组件等
2、服务器支持SSL通信时，报文中包含SSL 版本、加密组件， 是从客户端给的列表中选择的
3、服务器发送公钥
4、5、6、客户端校验公钥合法后，会随机生成一个key，用作后续通信的加密秘钥，并且用服务端的公钥加密发送给服务端。（之所以要随机生成一个key，是因为通过公钥加密消息太过复杂，消耗资源过多）
步骤3，怎么防止公钥被调包问题
数字证书
如果服务端发送公钥给客户端时，被中间人替换了怎么办？下面给一个图，可以更
简单的理解
公钥被调包的问题出现，是因为我们的客户端无法分辨返回的公钥是服务端的还是是中间人。问题的难点是如果我们选择直接将公钥传递给客户端的方案，我们始终无法解决公钥传递被中间人调包的问题。
所以，我们不能直接将服务器的公钥传递给客户端，而是第三方机构使用它的私钥对我们的公钥进行加密后，再传给客户端。客户端再使用第三方机构的公钥进行解密。这也就是数据证书
客户端拿到服务端返回的证书后，就可以使用第三方机构的公钥来解密，并判断证书是否合法。
数字签名
但是这个第三方机构是可以给很多人发放证书的，那怎么来保证这个证书没有被中间人替换呢。只要是同一家第三方机构，那么该机构的公钥就可以解密该机构发放的所有数字证书。
数字签名，解决同一机构颁发的不同证书被篡改问题
要解决这个问题，我们首先要想清楚一个问题，辨别同一机构下不同证书的这个职责，我们应该放在哪？
只能放到客户端了。客户端在拿到证书后，自己就有能力分辨证书是否被篡改了。如何才能有这个能力呢？
我们从现实中找灵感。比如你是HR，你手上拿到候选人的学历证书，证书上写了持证人，颁发机构，颁发时间等等，同时证书上，还写有一个最重要的：证书编号！我们怎么鉴别这张证书是的真伪呢？只要拿着这个证书编号上相关机构去查，如果证书上的持证人与现实的这个候选人一致，同时证书编号也能对应上，那么就说明这个证书是真实的。
可是，这个“第三方机构”到底是在哪呢？是一个远端服务？不可能吧？如果是个远端服务，整个交互都会慢了。所以，这个第三方机构的验证功能只能放在客户端的本地了。
客户端本地怎么验证证书呢？答案是证书本身就已经告诉客户端怎么验证证书的真伪。
也就是证书上写着如何根据证书的内容生成证书编号。客户端拿到证书后根据证书上的方法自己生成一个证书编号，如果生成的证书编号与证书上的证书编号相同，那么说明这个证书是真实的。同时，为避免证书编号本身又被调包，所以使用第三方的私钥进行加密。
