一、认证：客户端第一次访问服务端时，要求服务端证明自己可被信任

1.证书：由服务端申请、第三方CA颁发的，存放在服务端的证书；

　　　　证书包含：服务端的公钥、服务端的基本信息（明文）、CA的信息、签名（对服务端公钥、基本信息摘要进行hash计算得到hash值，然后使用CA的秘钥对该hash值进行加密后的密文）

2.证书作用：当客户端访问服务端时，服务端发送证书（给客户端检查）证明自己已在第三方CA登记，可被信任。

　　参考：https://www.cnblogs.com/handsomeBoys/p/6556336.html

　　　　    https://blog.csdn.net/lwwl12/article/details/80691746     CA、根证书与数字证书

　　　　　https://www.cnblogs.com/fps2tao/p/10036910.html

　　　　　https://segmentfault.com/a/1190000002554673

注意：

2.1 客户端如何验证服务端发送的证书，证明服务端可被信任

　　客户端需要事先安装第三方CA的根证书（CA中心颁发给CA中心自己的证书），该根证书下的所有证书都将被客户端信任。

　　客户端拿到服务端的证书后，读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，

然后利用对应 CA 的公钥（CA根证书）解密签名，得到服务端公钥及其他信息；解密得到的信息与证书中公开的信息对比（？），如果一致，则可以确认证书合法（即服务端被信任 ，服务端的公钥是其真实的公钥）

2.2 客户端可以要求验证服务端，同样，服务端也可以要求验证客户端 （这种情况较少，如金融服务要求验证客户端）

　　原理基本相同，客户端有自己CA证书，访问服务端时，发送自己CA证书给服务端检查。

2.3 证书可以有第三方颁发，也可以由服务端自己制作（服务端自己颁发给自己的）。

　　OpenSSL

二、密钥商定（TLS握手）

1.密钥商定：对称加密 + 非对称加密

　　得到通信加密的秘钥。

　　参考：https://www.cnblogs.com/xiohao/p/9054355.html

2.开始使用商定的密钥https加密通信

附录： https 完整的认证+密钥商定过程

参考：https://segmentfault.com/a/1190000002554673

假设A与B通信，A是客户端，B是服务器端

----------- 加密后的消息放在方括号[]里，以突出明文消息的区别。双方的处理动作的说明用圆括号（）括起。

A：我想和你安全的通话，我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH，摘要算法有MD5和SHA。

B：我们用DES－RSA－SHA这对组合好了。
这是我的证书，里面有我的名字和公钥，你拿去验证一下我的身份（把证书发给A）。
目前没有别的可说的了。

A：（查看证书上B的名字是否无误，并通过手头早已有的CA的证书验证了B的证书的真实性，如果其中一项有误，发出警告并断开连接，这一步保证了B的公钥的真实性）
（产生一份秘密消息，这份秘密消息处理后将用作加密密钥，加密初始化向量（IV）和hmac的密钥。将这份秘密消息-协议中称为per_master_secret-用B的公钥加密，封装成称作ClientKeyExchange的消息。由于用了B的公钥，保证了第三方无法窃听）
我生成了一份秘密消息，并用你的公钥加密了，给你（把ClientKeyExchange发给B）
注意，下面我就要用加密的办法给你发消息了！
（将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥）
[我说完了]

B：（用自己的私钥将ClientKeyExchange中的秘密消息解密出来，然后将秘密消息进行处理，生成加密密钥，加密初始化向量和hmac的密钥，这时双方已经安全的协商出一套加密办法了）
注意，我也要开始用加密的办法给你发消息了！
[我说完了]

A: [我的秘密是…]

B: [其它人不会听到的…]