自建CA本地搭建https
//第一步，为服务器端和客户端准备公钥、私钥
# 生成服务器端私钥
openssl genrsa -out server.key 1024
# 生成服务器端公钥
openssl rsa -in server.key -pubout -out server.pem
//第二步，生成 CA 证书
# 生成 CA 私钥
openssl genrsa -out ca.key 1024
# X.509 Certificate Signing Request (CSR) Management. ca证书签名请求
#要求填写一些资料。Common Name是能访问的域名
openssl req -new -key ca.key -out ca.csr
# X.509 Certificate Data Management. 生成ca证书
openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt
//第三步，生成服务器端证书
# 服务器端需要向 CA 机构申请签名证书，在申请签名证书之前依然是创建自己的 CSR 文件
openssl req -new -key server.key -out server.csr
# 向自己的 CA 机构申请证书，签名过程需要 CA 的证书和私钥参与，最终颁发一个带有 CA 签名的证书
openssl x509 -req -CA ca.crt -CAkey ca.key -CAcreateserial -in server.csr -out server.cr
之后再配置nginx的ssl即可
接下来通过WireShark抓包分析https协议的交互过程
- 客户端首先向服务器端发送一个 Client Hello 的 SSL 握手信息。
虽然只有 Client Hello 两个单词，但是其消息体里面包含了丰富的信息，我们在 WireShark 上选择这行记录，并双击，其里面包含了下面的一些主要信息。
（1）Handshake Type：Client Hello（握手类型）。
（2）Random（随机数）和一个时间戳。
（3）客户端支持的加密协议套装。
告诉 HTTPS 的服务器端，客户端能支持上面这 26 种加密协议套装上列出的算法，让服务器选择一个加密协议算法套装。
（4）访问的 Web 服务器的信息：
（5）客户端支持的签名算法：
客户端告诉服务器其支持 9 种签名算法，让服务器端自由选择一个用于后续的加密通信。
2. HTTPS 服务器马上给客户端回复 4 条 SSL 握手信息
HTTPS 服务器马上给客户端回复了下面这 4 条 SSL 握手信息。
- Server Hello
- Certificate
- Server Key Exchange Server
- Hello Done
下面具体来看这 4 条由 HTTPS 服务器端发出的 4 条消息里面到底有什么内容，其会告诉客户端什么秘密和信息呢？
（1）Server Hello SSL 握手信息
其重点是把客户端发送给服务器端的随机数又给发送回去了，而且还生成了服务器端的 Session ID 并发送给客户端，最后告诉客户端，服务器端准备选择TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384作为秘钥交互的加密协议套装，该加密协议的套装名字肯定出现在客户端发送给服务器的支持的 26 个列表中，不信你可以翻回去对比一下。
（2）Certificate
SSL 服务器证书信息。在这条 HTTPS 服务器给客户端回复消息 SSL 握手信息里面，其还会把服务器端的 SSL 证书发送给客户端，从上图的转包信息中，我们能清晰地发现服务器端 SSL 证书的相关信息，比如，通用名字为 iis-web-01，组织单元为 it 等。
需要注意的是，如果是 SSL 的双向认证，服务器端也可以要求客户端把 SSL 证书发送给服务器端（对应的 SSL 握手消息名称为：CertificateRequest），这个时候，客户端就会把其 SSL 证书发送给服务器端，从而证明其就是服务器端信任的客户端。
（3）Server Key Exchange 握手消息
HTTPS 服务器出大招了，告诉了客户端其将会采用的 EC Diffie-Hellman 算法进行 HTTPS 服务器和客户端的秘钥交换。具体什么是 EC Diffie-Hellman 算法，大家可以自行查阅资料，这里不再赘述，并提供了 EC Diffie-Hellman 算法使用到的服务器端的参数：
- 曲线类型：
named_curve: secp256r1 - 公钥信息
- 签名的算法：
rsa_pkcs1_sha1 - 签名的信息
（4）Server Hello Done 握手信息
握手信息列表结束了。
3. HTTPS 客户端马上给服务器端回复 3 条 SSL 握手信息
当客户端收到服务器端的相关公钥信息，SSL 证书以及摘要算法和摘要信息后，也不是无动于衷，而是积极的响应了下面的 3 条 SSL 握手信息。
- Client Key Exchange
- Change Cipher Spec
- Encrypted Handshake Message
那么这三条 SSL 的握手信息将会透露出什么？客户端到底想告诉服务器端什么？让我们一一分解。
（1）Client Key Exchange 握手信息
其给服务器端发送了一条用服务器端公钥加密的信息，其里面就包含了预备主密码（Pre-Master secret），其是由客户端随机生成，之后会被用作生成主密码的种子。根据预备密码，服务器和客户端会计算出相同的主密码（Master secret），然后根据主密码生成下面的比特序列（秘钥素材）。
- 对称密码的秘钥
- 消息认证码的秘钥
- 对称密码的 CBC 模式中使用的初始化向量（IV）
需要注意的是，Client 秘钥交换的方式主要有两种，一种是通过 RSA 公钥密码进行交互，这个时候客户端会在发送 ClientKeyExchange 消息时，将经过加密的预备主密码一起发送给服务器。当使用 Diffie-Hellman 交换秘钥的时候，客户端会在发送 ClientKeyExchange 消息时，将 Diffie-Hellman 公开值（Pub Key）一起发送给服务器，根据这个值，客户端和服务器会各自生成预备主密码，而且更加这个预备主密码能够生成相同的对称主密码。
（2）Change Cipher Spec 握手信息
告诉服务器端，我要切换密码了！
（3）Encrypted Handshake Message 握手信息
客户端发出使用主密码加密的结束信息，告诉服务器端：“秘钥交换握手协议到此结束”。
4. HTTPS 服务端马上给客户端回复 2 条 SSL 握手信息
这次轮到服务器端发送“Change Cipher Spec”消息了，服务器告诉客户端：“好，现在我也要切换密码了”。
服务器端用预备主密码（Pre-Master secret）计算出的主秘钥加密了一条信息，并发送给客户端：“好的，秘钥交换握手协议到此结束”。如果通信双方都能把结束消息解密成功，说明主秘钥已经交换成功。就可以发送真正的用主密码加密的应用数据的信息了！
5. 服务端用对称秘钥把加密过的 HTML 网页内容发送给客户端
服务器端用成功交换了秘钥把加密过的 HTML 网页内容发送给客户端，客户端用以前收到过的对称秘钥进行解密，HTTPS 通信协议圆满结束。
上面的步骤只是把我当前环境下抓取到的使用 TL S1.2 协议规范进行了 HTTPS 通信原理和过程的梳理和解释，在不同的环境下，其通信过程会有一些差异，比如，如果配置了双向 SSL 认证，其 SSL 服务器端还会要求客户端把客户端的证书发送到服务端，从而验证客户端是否是可信任的，另外在进行主密码交换的过程中，也可能采用 RSA 公钥密码，而不是 Diffie-Hellman，此时，其 SSL 握手消息会有所不同，但是整体的流程和交互过程思路基本上保持相同。
上述具体流程如下图所示
本文亦在微信公众号【小道资讯】发布，欢迎扫码关注！
