非对称加密的又一大应用是SSL。对于SSL的介绍，阮一峰有一篇深入浅出的博客，推荐阅读：数字签名是什么？。这篇文章也非常不错：SSL/TLS Strong Ebcryption: An introduction。
SSL协议对互联网的安全十分重要。要理解SSL协议，必须先理解几个基本概念：信息摘要(message digest)，数字签名(digital signature)，数字证书(digital certificate)。阮一峰的博客里写得十分清楚了，看完后做一点自己的笔记。
SSL术语
公钥(public key): 非对称加密密钥对中可以分发给其它人的一方。
私钥(private key): 非对称加密密钥对中自己保存的一方。
信息摘要(message digest): 对一段很长的数据消息，计算它的Hash函数值，得到的一串*较短*且*定长*的短数值。Hash函数可以是MD5或者SHA 1。Hash函数过程是单向不可逆的，不可能通过message digest 反推出原数据信息。同时，message digest也是独一无二的。可以理解为某一段数据内容独一无二的特征值。
数字签名(digital signature): 使用用户私钥对信息摘要(message digest)进行加密，生成的信息。数字签名只能用用户的公钥解开。反过来，如果用户Alice的公钥成功解密了数字签名，那么一定能确定这个签名的签发者是用户Alice(因为只可能是Alice的私钥签发了它)。
数字证书(digital certificate): 由某个被信任的机构(如Certificate Authority，CA)签发、认证用户身份的数字文件。(数字证书的内容复杂，将在另外一篇博客中专门介绍)。
SSL基本原理
这里介绍的是SSL的设计思想和大致原理，不是实现细节。转述自从阮一峰的博客。
假设用户Alice有属于自己的公钥/私钥对。她准备和好朋友Bob，Susan等通信。
- Alice把自己的公钥送给朋友们：Bob，Susan每人一把。
- Bob如果要给Alice写一封保密的信，那么他写完后用Alice的公钥加密，就可以达到保密的效果。
- Alice收到信后，用自己私钥解密，就看到了信件内容。这里要强调的是，只要Alice的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。
试思考：如果Alice事先没有把自己公钥送给自己的朋友们，她自己手中也没有朋友们的公钥，那他们之间通信如何保证不被篡改？
假设Alice要给Bob写信。她写好信(message)后，先使用Hash函数生成信息摘要(message digest)。然后，她使用私钥，对这个摘要加密，生成数字签名(digital signature)。最后，她把自己的信件内容、数字签名，还有自己的公钥一起发送给Bob。
Bob收到了信件。他取出Alice的公钥、数字签名，用公钥解密数字签名，得到信息摘要;他再读出信件内容，用Hash函数自己计算内容的信息摘要。如果取出来的摘要和算出来的摘要吻合，那么这封信就未被修改过。
可是，万一黑客John截获了Alice发给Bob的信件，然后自己编造了一些内容，生成摘要、用自己密钥加密生成数字签名，再连同自己的公钥一起发给Bob，他就可以冒充Alice了。Bob如何确定取出的公钥就是Alice的，而不是别人(例如，黑客John)的？
Bob无法确定公钥是不是属于Alice，于是想到一个办法：他建议Alice去找权威机构(例如，certificate authority，简称CA)给她的公钥做认证，做个证书(certificate)。Alice领取了一份申请表格，填入自己的姓名、住址、联系方式、和自己的公钥，跑到CA去提交。CA接受申请，确认是Alice本人无误，就用自己的私钥处理Alice的表格内容，生成数字签名并附在申请表格后面，这就成了“数字证书”(digital ceritificate)。
以后Alice给Bob写信，就会发送信件内容+数字签名+数字证书三部分。Bob收到来信，先检查数字证书的真伪。如果为真，那么从数字证书中取出Alice的公钥。这时可以确认得到的是Alice的真实公钥。
数字证书的现实应用：https中的SSL协议
- 首先，客户端向服务器发出加密请求。
- 服务器用自己的私钥加密网页，连同本身的数字证书，一起发送给客户端。
- 客户端打开自己的“证书管理器”，看证书是否由“受信任的根证书颁发机构”颁发。
- 如果证书合法，而且确实颁发给你所浏览的网址的，那么客户端就可以取出真实的公钥。否则客户端会提出警告。
思考：SSL协议的实现流程，与SSL certificate的实现细节
这篇文章为了解释SSL协议的原理，引入并介绍了“摘要”“数字签名”“数字证书”等概念。这篇文章主要介绍原理，而且用了比喻，可能在细节上有出入，这是需要注意的。在实际的互联网环境中，SSL协议的实现更为复杂精细。
但就谈到的点而言，可能还存在这样的疑问：
> 客户端(浏览器)如何确认一份数字证书的真伪？
这个问题值得思考。为了确认公钥是真实的，我们引入了“数字证书”为它担保——问题只不过换了一种问法，但信任锚点还是没能确认。在下一篇文章中，会讨论数字证书的细节，并介绍如何确认一份“数字证书”的真伪。