标签：记录 服务器 网页 根证书 img 说话 分享 iges 接收
背景：项目中为了保证通信的安全，经常要用到公钥私钥相关方面的知识，所以有必要彻底的了解一下。
今天，我读到一篇好文章。
它用图片通俗易懂地解释了，"数字签名"（digital signature）和"数字证书"（digital certificate）到底是什么。
我对这些问题的理解，一直是模模糊糊的，很多细节搞不清楚。读完这篇文章后，发现思路一下子就理清了。为了加深记忆，我把文字和图片都翻译出来了。
文中涉及的密码学基本知识，可以参见我以前的笔记。
====================================================
数字签名是什么？
作者：David Youd
翻译：阮一峰
原文网址：http://www.youdzone.com/signature.html
1.
鲍勃有两把钥匙，一把是公钥，另一把是私钥。
2.
鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。
3.
苏珊要给鲍勃写一封保密的信。她写完后用鲍勃的公钥加密，就可以达到保密的效果。
4.
鲍勃收信后，用私钥解密，就看到了信件内容。这里要强调的是，只要鲍勃的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。
5.
鲍勃给苏珊回信，决定采用"数字签名"。他写完后先用Hash函数，生成信件的摘要（digest）。
6.
然后，鲍勃使用私钥，对这个摘要加密，生成"数字签名"（signature）。
7.
鲍勃将这个签名，附在信件下面，一起发给苏珊。
8.
苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。
9.
苏珊再对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。
10.
复杂的情况出现了。道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成"数字签名"，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。
11.
后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找"证书中心"（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。
12.
鲍勃拿到数字证书以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字证书就行了。
13.
苏珊收信后，用CA的公钥解开数字证书，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。
14.
下面，我们看一个应用"数字证书"的实例：https协议。这个协议主要用于网页加密。
15.
首先，客户端向服务器发出加密请求。
16.
服务器用自己的私钥加密网页以后，连同本身的数字证书，一起发送给客户端。
17.
客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。
18.
如果数字证书记载的网址，与你正在浏览的网址不一致，就说明这张证书可能被冒用，浏览器会发出警告。
19.
如果这张数字证书不是由受信任的机构颁发的，浏览器会发出另一种警告。
20.
如果数字证书是可靠的，客户端就可以使用证书中的服务器公钥，对信息进行加密，然后与服务器交换加密信息。
决心花一些时间，将这些概念和使用的过程彻底弄清楚。最先找到的文章是：数字签名是什么？（阮一峰博客），读了一遍，又找了一些资料，终于把这些概念弄清楚了，这里整理记录一下。
首先明确几个基本概念：
1、密钥对，在非对称加密技术中，有两种密钥，分为私钥和公钥，私钥是密钥对所有者持有，不可公布，公钥是密钥对持有者公布给他人的。
2、公钥，公钥用来给数据加密，用公钥加密的数据只能使用私钥解密。
3、私钥，如上，用来解密公钥加密的数据。
4、摘要，对需要传输的文本，做一个HASH计算，一般采用SHA1，SHA2来获得。
5、签名，使用私钥对需要传输的文本的摘要进行加密，得到的密文即被称为该次传输过程的签名。
6、签名验证，数据接收端，拿到传输文本，但是需要确认该文本是否就是发送发出的内容，中途是否曾经被篡改。因此拿自己持有的公钥对签名进行解密（密钥对中的一种密钥加密的数据必定能使用另一种密钥解密。），得到了文本的摘要，然后使用与发送方同样的HASH算法计算摘要值，再与解密得到的摘要做对比，发现二者完全一致，则说明文本没有被篡改过。
上面实际上介绍了加密解密和数字签名两个概念和实现过程，二者的过程正好是相反的。
在签名的过程中，有一点很关键，收到数据的一方，需要自己保管好公钥，但是要知道每一个发送方都有一个公钥，那么接收数据的人需要保存非常多的公钥，这根本就管理不过来。并且本地保存的公钥有可能被篡改替换，无从发现。怎么解决这一问题了？由一个统一的证书管理机构来管理所有需要发送数据方的公钥，对公钥进行认证和加密。这个机构也就是我们常说的CA。认证加密后的公钥，即是证书，又称为CA证书，证书中包含了很多信息，最重要的是申请者的公钥。
CA机构在给公钥加密时，用的是一个统一的密钥对，在加密公钥时，用的是其中的私钥。这样，申请者拿到证书后，在发送数据时，用自己的私钥生成签名，将签名、证书和发送内容一起发给对方，对方拿到了证书后，需要对证书解密以获取到证书中的公钥，解密需要用到CA机构的”统一密钥对“中的公钥，这个公钥也就是我们常说的CA根证书，通常需要我们到证书颁发机构去下载并安装到相应的收取数据的客户端，如浏览器上面。这个公钥只需要安装一次。有了这个公钥之后，就可以解密证书，拿到发送方的公钥，然后解密发送方发过来的签名，获取摘要，重新计算摘要，作对比，以验证数据内容的完整性。
这里纯粹的文字，未免枯燥，可以结合前面提到的文章链接中的图片一起理解，这些文字对图片的理解应该有一些帮助。HTTPS是综合用了加密解密和数字签名的实例，理解了上述概念和过程，结合密钥对交换的过程就不难理解HTTPS。
标签：记录 服务器 网页 根证书 img 说话 分享 iges 接收
原文地址：http://www.cnblogs.com/lixuwu/p/7693603.html
