客户端认证服务端证书的过程

https://www.cnblogs.com/zfxJava/p/5295957.html

###

消息-->[公钥]-->加密后的信息-->[私钥]-->消息

###

加密：防窃听（私钥）（对签名加密，形成数字签名）（古典加密主要以保护算法为主，现代加密主要以保护密钥为主）

签名：防篡改（hash签名，并附加上原文一起发送）（权威机构给证书卡的一个章，即签名算法）

我们怎么确认CA的公钥就是对的呢，层层授信背书（CA的公钥也需要更牛的CA给它签名，只要上级证书的公钥，可以解开CA的签名，就可以。层层上去，直到全球皆知的几个著名的大CA）

在web数据传输过程中，由于客户端和服务器端是多对一的关系，因此可以让所有的客户端持有相同的公钥，服务器持有私钥，这样一来就能方便地实现数据的加密传输

浏览器与Web Server之间要经过一个握手的过程来完成身份鉴定与密钥交换，从而建立安全连接。具体过程如下：  
用户浏览器将其SSL版本号、加密套件候选列表、压缩算法候选列表等有关的数据以及一个随机数发送到服务器。  

服务器将其选择使用的协议版本、加密套件、压缩算法等有关的数据以及一个随机数发送给浏览器，同时发给浏览器的还有服务器的证书。如果配置服务器的SSL需要验证用户身份，还要发出请求要求浏览器提供用户证书。  

客户端检查服务器证书，如果检查失败，提示不能建立SSL连接。如果成功，那么继续。客户端浏览器为本次会话生成Pre-Master secret，发送Client Key Exchange，并将其用服务器公钥加密后发送给服务器。如果服务器要求鉴别客户身份，客户端还要再对另外一些数据签名后并将其与客户端证书一起发送给服务器。  

到目前为止，无论客户端还是服务器都有了三个随机数，自己的，对端的以及刚生成的Pre-Mastert随机数。通过这三个随机数，可以在客户端和服务器产生相同的对称密钥。这样做的主要原因是对称加密比非对称加密的运算量低一个数量级以上，能够显著提高双方会话时的运算速度。

整个过程涉及2对公私密钥对，一对由服务器产生，用于加密，一对由CA产生，用于签名。
整个过程还涉及2个信任：客户端信任CA，CA发布的证书中的公钥就是合法服务器的公钥。客户端信任浏览器内置的CA公钥就是与CA私钥对应的公钥。最后要说明的是，非对称加密在https中只是用来对对称加密密钥进行协商的过程才使用，在两端协商完对称加密的密钥之后，数据的加密传输均采用对称加密的方式。

因为黑客也有服务器的公钥，所以在截取后可以打开服务器的密文，也可以模拟客户端获取一些信息。所以最好是两对公私钥，客户端用服务器的公钥加密传输，服务器用客户端的公钥加密传输

对于重放和篡改，通过timestamp和nonce随机数联合起来，保证唯一，对于同样的请求，只接受一次