https协议数据交互原理，数字签名、公钥、私钥、CA证书之间的关系
**
非对称加解密，私钥和公钥到底是谁来加密，谁来解密
**
第一种用法：公钥加密，私钥解密。—用于加解密
第二种用法：私钥签名，公钥验签。—用于签名
有点混乱，不要去硬记，总结一下:
你只要想：
既然是加密，那肯定是不希望别人知道我的消息，所以只有我才能解密，所以可得出公钥负责加密，私钥负责解密；
既然是签名，那肯定是不希望有人冒充我发消息，只有我才能发布这个签名，所以可得出私钥负责签名，公钥负责验证。
同一种道理，我在换种说法：
私钥和公钥是一对，谁都可以加解密，只是谁加密谁解密是看情景来用的：
第一种情景是签名,使用私钥加密,公钥解密,用于让所有公钥所有者验证私钥所有者的身份并且用来防止私钥所有者发布的内容被篡改.但是不用来保证内容不被他人获得。
第二种情景是加密,用公钥加密,私钥解密,用于向公钥所有者发布信息,这个信息可能被他人篡改,但是无法被他人获得。
比如加密情景：
如果甲想给乙发一个安全的保密的数据,那么应该甲乙各自有一个私钥,甲先用乙的公钥加密这段数据,再用自己的私钥加密这段加密后的数据.最后再发给乙,这样确保了内容即不会被读取,也不会被篡改.
解说如下：
鲍勃有两把钥匙，一把是公钥，另一把是私钥。
鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。
苏珊要给鲍勃写一封保密的信。她写完后用鲍勃的公钥加密，就可以达到保密的效果
鲍勃收信后，用私钥解密，就看到了信件内容。这里要强调的是，只要鲍勃的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。
鲍勃给苏珊回信，决定采用** “数字签名”**。他写完后先用Hash函数，生成信件的摘要（digest）
然后，鲍勃使用私钥，对这个摘要加密，生成"数字签名"（signature）。
鲍勃将这个签名，附在信件下面，一起发给苏珊。
苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。
苏珊再对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。
复杂的情况出现了。道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成"数字签名"，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。
后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找"证书中心"（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。
鲍勃拿到数字证书以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字证书就行了。
苏珊收信后，用CA的公钥解开数字证书，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。
下面，我们看一个应用"数字证书"的实例：https协议。这个协议主要用于网页加密。
首先，客户端向服务器发出加密请求。
发送请求
服务器用自己的私钥加密网页以后，连同本身的数字证书，一起发送给客户端。
服务器加密后发送
客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。
受信任证书验证
如果数字证书记载的网址，与你正在浏览的网址不一致，就说明这张证书可能被冒用，浏览器会发出警告。
证书存在问题
19 .如果这张数字证书不是由受信任的机构颁发的，浏览器会发出另一种警告
发出另一种警告
20.如果数字证书是可靠的，客户端就可以使用证书中的服务器公钥，对信息进行加密，然后与服务器交换加密信息。
总之
数字签名 就是使用个人私密和加密算法加密的摘要和报文，是私人性的,而数字证书是由CA中心派发的,具有一定的权威性，一般无法进行伪造。
HTTPS单向认证
Https在建立Socket连接之前，需要进行握手，具体过程如下：
客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息;
服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书;
客户端使用服务端返回的信息验证服务器的合法性，包括：
证书是否过期;
发行服务器证书的CA是否可靠;(通过查询浏览器或本机内的CA证书)
返回的公钥是否能正确解开返回证书中的数字签名;（通过使用本机或浏览器内置的CA公钥进行解密）
服务器证书上的域名是否和服务器的实际域名相匹配;
验证通过后，将继续进行通信，否则，终止通信;
客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择;
服务器端在客户端提供的加密方案中选择加密程度最高的加密方式;
服务器将选择好的加密方案通过明文方式返回给客户端;
客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器;
服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥;
在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全;
HTTPS双向认证
双向认证和单向认证类似，它额外增加了服务端对客户端的认证：
客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息;
服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书;
客户端使用服务端返回的信息验证服务器的合法性，包括：
证书是否过期;
发行服务器证书的CA是否可靠;(通过查询浏览器或本机内的CA证书)
返回的公钥是否能正确解开返回证书中的数字签名;（通过使用本机或浏览器内置的CA公钥进行解密）
服务器证书上的域名是否和服务器的实际域名相匹配;
验证通过后，将继续进行通信，否则，终止通信;
服务端要求客户端发送客户端的证书即客户端证书公钥，客户端会将自己的证书发送至服务端；
验证客户端的证书，通过验证后，会获得客户端的公钥；
客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择
服务器端在客户端提供的加密方案中选择加密程度最高的加密方式;
将加密方案通过使用之前获取到的公钥进行加密，返回给客户端
客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端；
服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全；