使用场景：客户端与服务端进行数据传输时，需要进行数据加密。
例：服务端自身创建一对公私密钥（公钥加密的数据只能由对应的私钥进行解密，反之同理），私钥由服务端自身保存（不泄露的前提下，私钥只有只有服务端自身才有），服务端将公钥告知于客户端，从而进行加密数据传输。
风险：服务端发送公钥给客户端时，被第三方拦截后，第三方可以知道服务端的公钥，并自身进行公私密钥对的创建，然后传递给客户端一个属于第三方的公钥，客户端在不知道公钥被替换的前提下，使用第三方的公钥进行加密数据传输，第三方依旧可以进行拦截，获取加密数据并使用自身的私钥进行数据解密，然后将解密后的真是数据进行篡改，再使用服务端的公钥进行数据加密发送给服务端，最后，服务端收到的数据并非是客户端的真是数据，而是经过篡改了。
解决方式：加入数字证书
作用：数据证书包含关键2点（1.加密服务端公钥 2.加密证书签名）
解释：数字证书颁发机构自身具有对应的公私密钥对，私钥没有人能知道，只有机构自身，公钥各大浏览器都支持，都保存有各大可信证书机构的公钥。
证书签名：将发送内容使用摘要算法，进行摘要计算，将对应的摘要进行加密（使用CA私钥，后续验证证书可靠性需要），得到签名。
加入证书后流程：服务端不再直接发送公钥给客户端，而是把公钥交给证书颁发机构，证书颁发机构使用自身的私钥对申请证书时提供的公钥进行加密，并且通过服务端网址等信息生成一个证书签名，证书完成后，把证书发送给服务端，当客户端请求来临时，服务端把申请的证书直接发给客户端，客户端根据自身浏览器中保存的证书公钥，对加密的公钥进行解密，得到服务端实际发布的公钥。
疑问：如果第三方自身生成一对公私密钥，并且将公钥发送给证书颁发机构进行证书生成，获得可信任证书机构的证书，然后替换服务端的证书发送给客户端呢？客户端依然可以用该信任的机构的公钥进行解密获取第三方的公钥。
解释：涉及证书的认证机制，客户端收到证书后，不光要解密证书的加密服务端公钥信息（获取服务端公钥），还要进行证书的真实性校验，假如现在客户端收到的证书是第三方的假证书，那么在进行数字签名信息解密时便会出现错误，因为已知的CA公钥只能解密使用对应的CA机构的私钥加密的数字签名，任何人无法伪造。
校验操作：
1.验证证书的真伪
当浏览器拿到一个数字证书，先看发证机关，然后找到相应的发证机关的证书，获得发证机关的公钥
，用此公钥解密被加密的MD5，这样就获得了此证书的MD5值，称它为Hash1。然后浏览器用MD5算法对
此证书重新计算一遍MD5，获得Hash2。然后比较Hash1和Hash2是否相等。如果相等就证明这张证书是
由发证机关颁发的，并且没有被篡改过.
2.验证持有者的真伪
核对持有证书人的身份。这就要依赖证书里面包含的公钥。此公钥是这张证书所有者的公钥（注意，
这里指的是所有者，而不是持有者！），用此公钥加密一段信息发送给证书的持有者，如果持有者能
发送回（可以是被私钥加密，也可以是明文，没有关系）被加密的这段信息的话就证明该持有者拥有
该证书对应的私钥，也就是说，该持有者就是该证书的所有者。
（接收者收到用公钥加密的信息，能用私钥解密发回或用私钥加密后发回）
3.验证证书所有者的姓名
证书中所有者的名字与认证中心（CA）登记的（Common Name）姓名是否一样(对服务器来说，域名是否一致）
