炒冷饭之 Https 建立链接

服务端-->> 客户端:服务器证书

接着服务器往客户端发了一个自己的证书，证书的内容一般是这样的

1.Cert

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

ificate Format Version

证书版本号,用来指定证书格式用的 X.509 版本号，用于目录查询。

2.Certificate Serial Number

证书序列号,证书颁发者指定证书唯一序列号, 以标识 CA 发出的所有证书，用于目录查询。

3.Signature Algorithm Identifier

签名算法标识,用来指定本证书所用的签名算法（如 SHA－1、RSA）。

4.Issuer

签发此证书的 CA 名称,用来指定签发证书的 CA 的可识别的唯一名称(DN, Distinguished Name)，用于认证。

5.Validity Period

证书有效期,指定证书起始日期（notBefore）和终止日期（notAfter），用于校验证书的有效性。

6.Subject

用户主体名称,用来指定证书用户的 X.500 唯一名称(DN)，用于认证。

7.Subject Public Key Information

用户主体公钥信息。

(1)Algorithm Identifier,算法标识。用来标识公钥使用的算法。

(2)Subject Public Key,用户主体公钥。用来标识公钥本身，用于加/解密和数字签名。

8.Issuer Unique ID

颁发者可选唯一标识，很少用。

9.Subject Unique ID

主体证书拥有者唯一标识，很少用。

10.Extensions

证书扩充部分(扩展域)，用来指定额外信息。

验证证书

验证的内容主要是两个：1、公钥的合法性。 2、证书的用户主体信息 公钥的校验可以通过证书链来验证，验证证书的用户主体信息可以避免拦截者通过向证书机构申请证书之后把证书返回给客户端。也就是说验证公钥的同时验证公钥提供者的身份是不是客户端要访问的服务端。sequenceDiagram 客户端->>服务端: Client Hello 服务端-->> 客户端: Server Hello 服务端-->> 客户端:服务器证书客户端->> 服务端:Premaster Secret 证书验证通过之后，客户端将前面的客户端随机数、服务端随机数生成一个 Premaster Secret，之后发给服务端，至此，服务端和客户端都拥有一份相同的客户端随机数、服务端随机数和 Premaster Secret。然后 client 和 server 会使用 Pseudo-Random Function 生成一个 Master Secret，Master Secret 用于在客户端和服务端两边生成：客户端加密密钥、服务端加密密钥、客户端 MAC Secret、服务端 MAC Secret。客户端加密密钥：用于加密客户端发送的消息。 服务端加密密钥：用于加密服务端发送的消息。 客户端 MAC Secret：用于对客户端发送的消息做 hash 算法用的 Secret。 服务端 MAC Secret：用于对服务端发送的消息做 hash 算法用的 Secret。为什么要客户端和服务端各自有一套加密密钥和 MAC Secret 呢？ 这样是为了防止拦截者把客户端发送的消息原封不动的返回给客户端，如果用的是同一套则客户端会认为这是服务端返回回来的消息。