HTTPS的整套认证体系，最终归结为**"我凭什么信任这把公钥是真的？"**
答案就是：因为它在我的操作系统出厂时就已经存在，而我相信我的操作系统厂商和那些CA机构经过了足够严格的审核。 可以理解为：我们把对物理世界的信任（对微软/Apple/Google等商业实体的信任）投射到了数字世界。只要这个初始条件成立，后面的密码学运算就牢不可破。这就是你所说的"基础"。
HTTPS最终方案：非对称加密 + 对称加密 + 证书认证
在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个 证书，证书包含了之前服务端的公钥, 也包含了网站的身份信息.
客户端进行认证
client第一次请求，得到返回结果，不仅仅得到了公钥，实际上client得到的是一个"证书"，CA机构签发的证书。
客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的).
- 判定证书的有效期是否过期
- 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
- 验证证书是否被篡改: 从操作系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的
注意：
在验证证书是否被篡改这一步，从操作系统中拿到的公钥，绝不是从返回的证书里面取出的网站公钥 ，而是CA（证书颁发机构）的公钥。
我把这两把完全不同的公钥做一个对比，你就清楚了：
公钥来源 在哪个证书里 谁持有对应的私钥 在本步骤中的用途 CA的公钥 操作系统内置的根证书里 CA机构自己 用来解密 网站证书上的数字签名，从而得到 hash1网站的公钥 网站返回的站点证书里 网站服务器持有 后续建立TLS加密会话 时用于协商密钥，不是用来验证签名的
常见问题：
中间人有没有可能篡改该证书？
由于中间人没有 CA 机构的私钥，所以无法 hash 之后用私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名，这个世界上只有CA机构有私钥，也就意味着，只有CA机构才有对数据进行签名的能力！
中间人整个掉包证书？
- 因为中间人没有 CA 私钥，所以无法制作假的证书
- 所以中间人只能向 CA 申请真证书，然后用自己申请的证书进行掉包
- 这个确实能做到证书的整体掉包，但是别忘记，证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能够识别出来。
- 永远记住：中间人没有 CA 私钥，所以对任何证书都无法进行合法修改，包括自己的
为什么签名不直接加密，而是要先 hash 形成摘要?
缩⼩签名密文的⻓度,加快数字签名的验证签名的运算速度
HTTPS通信的完整流程：
总结 HTTPS 工作过程中涉及到的密钥有三组：
- 第一组(非对称加密): 用于校验证书是否被篡改. 服务器持有私钥(私钥在形成 CSR 文件与申请证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器在客户端请求时，返回携带签名的证书. 客户端通过这个公钥进行证书验证, 保证证书的合法性，进一步保证证书中携带的服务端公钥权威性。
- 第二组(非对称加密): 用于协商生成对称加密的密钥. 客户端用收到的 CA 证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.
- 第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密.
其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的！