到这里，已经可以保证服务器公钥的可靠性了，如果想要验证客户端的可靠性，同理，客户端这边也使用数字证书来签名，服务端收到后进行同样的签名校验即可
。这就是双向认证。
TLS协议，是由SSL协议升级而来，为了解决：
（1） 所有信息都是加密传播，第三方无法窃听。
（2） 具有校验机制，一旦被篡改，通信双方会立刻发现。
（3） 配备身份证书，防止身份被冒充。
https tls采用的方案就是我们上面所说的最后的证书中心+对称加密+非对称加密。
我们还是以客户端和服务端来说明：
1. 客户端给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
2. 服务端确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
3. 客户端确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给服务端。
4. 服务端使用自己的私钥，获取客户端发来的随机数（即Premaster secret）。
5. 服务端和客户端根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。
整个握手过程画成一张图就是这样：
握手阶段用来建立SSL连接。如果出于某种原因，对话中断，就需要重新握手。
这时有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。
session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录
，双方就可以重新使用已有的"对话密钥"，而不必重新生成一把。
session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对
话。session ticket就是为了解决这个问题而诞生的。
客户端不再发送session ID，而是发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对
话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。
链接直达：自签证书生成
（完）
参考链接https://zhuanlan.zhihu.com/p/43789231