开门见山地说，众所周知，HTTPS=HTTP+SSL/TLS，使用非对称加密算法+对称加密算法的混合加密算法。
最近在面试过程中被问到几次这个问题，看过几篇博客，说的都不是很清楚，理解也有偏差，毫无意外的面试都挂了，今天看到了阮一峰老师的博客——图解SSL/TLS
协议，终于有一种醍醐灌顶的感觉。
关键点
- 对称加密算法的秘密密钥用于加密正文数据（即建立SSL连接后客户端与服务器之间传输的用户数据）
- 非对称加密算法用来保证对称加密算法的秘密密钥的传递（客户端生成秘密密钥，传递给服务器）
整体流程
- 五次握手建立SSL连接：该部分主要为了产生后续传输数据的秘密密钥
- 建立连接后，后续就与非对称加密算法没有关系了，后续使用对称加密的秘密密钥进行数据交互。
SSL五次握手
先上图（图片出自阮一峰老师的博客，地址在文章开头）
下面流程中的公钥和私钥均指非对称加密算法的公钥和私钥）
- 客户端发送
client random——随机数1和cipher suites supported——客户端支持的加密算法给服务器 - 服务器把
server random——随机数2、对称加密算法（在客户端支持的加密算法范围中确认一个）以及包含公钥证书发送给客户端 - 客户端接收到第二步的信息之后，需要确认公钥证书（记住这个证书只包含公钥）是来自服务器的，这我们后面再说，确认之后，生成一个
Premaster secret——随机数3（预主密钥），并使用公钥证书中的公钥加密Premaster secret，得到Encrypted premaster secret并将其发送给服务器 - 服务器收到
Encrypted premaster secret并使用私钥解密得到Premaster secret。（OK，到此为止，客服端和服务器均有了随机数1、随机数2和随机数3） - 客服端和服务器使用三个随机数和第二步约定的加密算法生成秘密密钥，用于后面传输数据时明文数据的加密
现在，SSL连接已经建立了，从上面的流程可以看出来：非对称加密算法只用过一次，非对称加密算法本身的性能消耗很大，使用频繁很消耗性能。
CA证书机构
刚刚我们上面遗留了一个问题，五次握手第二步服务器发送给客户端的公钥证书有可能被中间人截取并篡改，那么客户端如何确认公钥证书是来自服务器而不是中间人呢？
这里CA证书机构就要上场了，在介绍这个过程前需要先介绍几个概念：摘要、数字签名
摘要：通过单向hash函数对原文进行哈希，将需加密的明文“摘要”成一串固定长度(如128bit)的密文，不同的明文摘要成的密文其结果总是不相同，同样的明文其摘要必定一致，并且即使知道了摘要也不能反推出明文。
数字签名：建立在公钥加密体制基础上，是公钥加密技术的另一类应用。它把公钥加密技术和数字摘要结合起来，形成了实用的数字签名技术。
（以上摘自https://blog.csdn.net/xiaoming100001/article/details/81109617）
CA证书申请流程
下面陈述中，单独的公钥私钥依然指服务器的公钥和私钥，CA私钥、公钥会特别说明
- 服务器S向CA机构提交公钥、组织信息、个人信息(域名)等信息并申请认证
- CA 通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等
- 如果审核通过则向S颁发证书，证书信息包含申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的
明文，同时包含一个签名，该签名生成方法：证书信息明文经过hash散列函数生成摘要，然后通过CA私钥对摘要进行加密生成的密文就是数字签名。
客户端验证公钥证书
OK，介绍了这么多，终于要介绍前面遗留的问题了。
- 现在的情况是，服务器拥有了CA机构颁发的证书和CA公钥，客户端拥有CA公钥（浏览器内置CA根证书）。
- 服务器将包含公钥的证书发送给客户端（这里指浏览器），证书中包含公钥、组织信息、有效期等信息，还有一个CA私钥加密过的数字签名。
- 客户端使用CA公钥对数字签名解密得到摘要1；客户端读取证书中的相关的明文信息，采用相同的散列函数计算得到摘要2，对比摘要1和摘要2，相等则说明证书有效。