之前读到一篇好文章，它用图片通俗易懂地解释了「数字签名」（Digital Signature）和「数字证书」（Digital Certificate）到底是什么，今天记录一下。
1
鲍勃有两把钥匙，一把是公钥，另一把是私钥。
2
鲍勃把公钥送给他的朋友们：帕蒂、道格、苏珊，每人一把。
3
苏珊要给鲍勃写一封保密的信，她写完后用鲍勃的公钥加密，就可以达到保密的效果。
4
鲍勃收信后，用私钥解密，就看到了信件内容。这里要强调的是，只要鲍勃的私钥不泄露，这封信就是安全的，即使信落在别人手里，也无法解密。
5
鲍勃给苏珊回信，为了防止信被修改，决定加上「数字签名」，于是他写完信后先用 Hash 函数，生成信件的摘要（Digest）。
6
然后，鲍勃再使用私钥，对这个摘要加密，生成「数字签名」（Signature）。
7
鲍勃将这个签名，附在信件下面，一起发给苏珊。
8
苏珊收信后，取下数字签名，用鲍勃的公钥解密，若成功得到信件的摘要，则证明这封信确实是鲍勃发出的。
9
苏珊再对信件本身使用同样的 Hash 函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。
10
有趣的情况出现了：道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃写信给苏珊，用自己的私钥做「数字签名」，让苏珊用假的鲍勃公钥进行解密。
【线下给密钥效率太低，实际还是通过网络分发密钥，所以在鲍勃分发公钥给帕蒂、道格、苏珊的时候（第 2 步），鲍勃的公钥就有可能被网络中间人截取，然后中间人把自己的公钥给这三个人，从而冒充鲍勃。后续这三个人加密消息都是用的中间人的公钥，中间人自然就可以解密看到消息，中间人解密消息以后可以再用鲍勃的公钥加密，转头发给鲍勃，而这些对鲍勃和他的朋友们来说根本意识不到。】
11
后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找有公信力的「证书中心」（Certificate Authority，简称 CA），为公钥做认证。CA 会将鲍勃的公钥和一些相关信息放在一起（原始数据），对它们进行哈希运算生成摘要，随后 CA 再用自己的私钥对该摘要进行加密，得到 CA 的数字签名，原始数据和 CA 的数字签名共同组成「数字证书」（Digital Certificate）。
12
鲍勃拿到数字证书以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字证书就行了。
13
苏珊收信后，与之前类似，先用 CA 的公钥解开数字证书中的签名，得到 CA 创建的摘要，然后对数字证书中的原始数据用同样的哈希算法再次生成摘要，两者一对比，如果一致，就说明原始数据未被篡改过，也就说明其中的公钥确实是鲍勃的，接着就可以用鲍勃的公钥对信件本身的签名进行解密、对比了。
14
下面，我们看一个应用「数字证书」的实例：HTTPS 协议（HTTPS = HTTP + TLS），这个协议主要用于网页加密。
15
首先，客户端向服务器发出加密请求。
16
服务器用自己的私钥加密网页以后，连同本身的数字证书（包含服务器的公钥、域名、有效期等，这些信息以明文形式存在，因为它们本身就是公开的，通过 CA 的数字签名可以验证这些明文信息是否被篡改过），一起发送给客户端。
17
客户端（浏览器）收到数字证书后，会根据预置的「受信任的根证书颁发机构」列表，查看解开 CA 的数字签名的公钥是否在列表之内（理论上，CA 的公钥也有可能被截取伪造，但是这样会导致如何安全传输公钥这个问题无限循环下去，所以必须要信任某个 CA 才行）。
18
如果不在列表之内，则说明这张数字证书不是由受信任的机构颁发，浏览器会发出警告。
19
如果数字证书中记录的域名与你正在浏览的域名不一致，则说明这张证书可能被冒用，浏览器会发出另一种警告。
20
如果数字证书是可靠的，客户端就可以安全获取到证书中的服务器公钥。
21
接着客户端生成随机的对称密钥，再用服务器的公钥加密，将其发送给服务器，服务器用自己的私钥进行解密，得到对称密钥。此时双方都知道了对称密钥，就可以用它来进行加密通信了（长期使用同一对称密钥可能泄露，因此 TLS 协议支持在特定时间或达到数据量阈值后重新协商对称密钥，第 15 到 21 步即为 TLS 的四次握手）。
22
也就是说，HTTPS 结合了非对称加密和对称加密两种方式，服务器通过非对称加密算法分发公钥，但最后实际通信使用的是对称加密算法。因为非对称加密虽然安全性很高，但速度却很慢，对称加密算法的加解密速度要比非对称加密算法快上百倍，适合处理大量数据，将两者配合使用，可以兼顾安全与性能。