SSL证书验证流程
前置说明
在学习 https 过程中，对于如何防止中间人攻击（MITMA）抱有疑问。
经了解发现，客户端是通过第三方机构 CA（Certificate Authorities）颁发的 SSL 证书验证服务器身份，之后再通过非对称加密的形式，协商对称加密的密钥，以此来实现安全通信。
对于非对称加密协商对称加密密钥这个过程，网上有很多学习资源，但对于 SSL 证书验证服务器身份流程的资源却很少。
所以，为了方便记忆，对SSL证书验证流程进行梳理和记录。
如有错误，请大家指正，谢谢。
数字签名
我们都知道，SSL 证书如果需要具有验证身份功能的话，无非是需要保证两点：
- 颁发机构权威
- 防篡改
发放 SSL 证书的机构都知道是 CA 机构，这没什么好说的。
主要是防篡改， SSL 证书是通过数字签名的方式，防止中间人（MITM）篡改公钥的。
下面对整个加密验证过程进行梳理。
1. 首先服务机构向 CA 申请 SSL 证书，提供企业信息，法人联系方式，域名等等企业信息。CA 机构验证后，会先自己生成一个证书，可以理解为可读的明文。（实际上是一个特定格式的数据文件，但此处为了理解做出抽象）
2. 验证通过，生成证书后， CA 机构会对明文证书进行Hash，得到摘要信息，并将摘要信息使用 CA 私钥 进行加密得到数字签名。之后将 证书明文内容+数字签名 返回到服务机构。
3. 当客户端和服务器握手时，服务器将 CA 机构生成的 证书明文内容+数字签名 发送给客户端。客户端通过操作系统或者浏览器内置信任的CA机构找到对应CA机构的公钥对数字签名进行解密，然后采用同样的摘要算法计算SSL证书的摘要，如果自己计算的摘要与服务器发来的摘要一致，则证书是没有被篡改过的！
注意： 一个是CA的公钥，内置在客户端，用来解密数字签名！另一个是目标服务器的公钥，在SSL证书内容里，用来协商对称密钥！
总结
1. 如何防止中间人攻击（MITMA）？
因为无论是什么机构都是没有 CA 私钥的（只有CA自己有），所以当中间人在修改协商公钥后，无法对数字签名重新加密。即使重新加密，在客户端用 CA 公钥解密后，因为中间人不是采用CA私钥加密的，所以客户端会发现多种摘要信息对比错误（例如企业信息、域名等等），这是就能判断，证书信息被修改过，正在握手的服务器不可信。
参考文章
https://server.zzidc.com/fwqcjwt/2999.html
