A.
client 连接请求发送到server, server根据配置，发送自己相应的证书给客户端的应用程序(通常是浏览器)，这时候的证书中含有的信息包括：证书的概要(明文信息)， 证书概要生成的hash值的加密值(这个hash值是被服务端证书对应的私钥加密过的). 证书概要中包含有哪些信息不在这里讨论.
B.
客户端收到证书之后，会从证书的概要中读取证书的发行机构，再查找自己的可信任证书列表，看证书的发行机构是否是可以信任的，如果不在可信任证书列表中，那么就会弹出：证书不可信的提示. 这时候需要信任根证书才可以继续.
C.
在”证书的发行机构“被信任之后(把发行机构的CA证书添加到可信任列表就可以完成)，继续从证书的概要中读取 服务端的证书的 公钥，并利用该公钥解密那个 被加密的hash, 从而获得证书概要的 hash. 然后 客户端的应用程序 还需基于证书概要的明文信息，根据指定的算法计算出实际的hash, 比较这个计算出来的hash 和那个解密出来的hash, 如果两者相等，那么证书验证成功，可以继续进行通信。如果两者不同，那么证书验证失败，通信至此结束.
D.
证书验证成功之后，客户端的应用会 通过这个证书和服务端进行一个加密的通信协商(公钥加密，私钥解密 / 私钥加密，公钥解密)，这个协商的目标是产生一个对称加密的密钥。
E.
密钥生成之后，那么就会 利用这个对称密钥进行通信了. 那么为什么不用密钥对的方式进行通信呢？
因为密钥对进行通信，那么在C/S 双方都会消耗更多的资源进行加解密操作，这个对通信的效率会有不少的影响，特别是传输大量数据的时候，对效率的影响就很明显，所以https的通信，都是用 密钥对协商一个 对称密钥，然后用对称密钥进行通信过程的加密，而不是一直用密钥对进行加解密.
网友评论