在雙鑰體系中攀例，公鑰用來加密信息嘉汰，私鑰用來數(shù)字簽名。
數(shù)字簽名
RSA 加密保障了信息的機(jī)密性摩疑，但無法保證信息的完整性
數(shù)字簽名是利用了私鑰加密信息摘要危融， 信息摘要可以保證數(shù)據(jù)的完整性，私鑰可以對(duì)發(fā)送者信息證明,（相當(dāng)于發(fā)送者在文件上簽名了一樣雷袋，所以叫數(shù)字簽名)
但其中還有一個(gè)問題吉殃，就是無法保證公鑰的來源性是否正確
比如如下一個(gè)問題:
a 生成一對(duì)公私鑰并把公鑰發(fā)給b, 隨后a就可以用自己的私鑰發(fā)送信息給b, b用手中的公鑰解密信息即可， 但假如有c在b的電腦上替換b的公鑰為c自己的公鑰楷怒， 那么c就可以用私鑰偽造a發(fā)送信息給b, 因?yàn)閎無法驗(yàn)證公鑰是否來自a還是來自c, 那么就會(huì)導(dǎo)致b誤認(rèn)為c發(fā)過來的信息和之前一樣還是a發(fā)送給他的
公私鑰就跟是鑰匙和鎖一樣總是成對(duì)而且是唯一的蛋勺，a生產(chǎn)鎖和鑰匙，把鑰匙給你鸠删，你用這把鎖去開門抱完，如果可以開對(duì)，那么就證明這把鎖是a的刃泡， c如果要偽造一把鎖是不可能的巧娱，但如果c把你的鑰匙和鎖都換成他自己的，那么你用c的鑰匙開c的鎖烘贴，自然是可以打開的禁添，但此時(shí)鎖卻不是a的
數(shù)字證書
數(shù)字證書就是為了解決這個(gè)公鑰的來源問題
a 把自己的公鑰給第三方權(quán)威機(jī)構(gòu)CA, 然后CA為a制作了一張包含a的公鑰和a的個(gè)人信息的數(shù)字證書， 下次a想給b發(fā)文件庙楚，只需要把該文件上荡， 文件的數(shù)字簽名趴樱，文件的數(shù)字證書都交給b, b從CA獲取CA的公鑰解密數(shù)字證書馒闷，就可以得到a的公鑰和a的信息，然后再用a的公鑰驗(yàn)證數(shù)字簽名叁征。
在這個(gè)過程中, b獲取公鑰是從CA獲取到的纳账，而不是b給他的，而且CA證書是定期會(huì)失效的捺疼，CA證書信息還包含權(quán)威機(jī)構(gòu)的認(rèn)證信息疏虫，別人是偽造不了的。
SSL
ssl 是https協(xié)議給http外加的一層隧道協(xié)議
這個(gè)協(xié)議主要用于網(wǎng)頁加密啤呼∥悦兀客戶端向服務(wù)器發(fā)出加密請(qǐng)求。服務(wù)器用自己的私鑰加密網(wǎng)頁以后官扣，連同本身的數(shù)字證書翅敌，一起發(fā)送給客戶端。
客戶端（瀏覽器）中會(huì)有一個(gè)證書管理器惕蹄， 有"受信任的根證書頒發(fā)機(jī)構(gòu)"列表蚯涮≈巫ǎ客戶端會(huì)根據(jù)這張列表，查看解開數(shù)字證書的公鑰是否在列表之內(nèi)遭顶。
如果瀏覽器發(fā)現(xiàn)用戶正在瀏覽的網(wǎng)址和數(shù)字證書中的網(wǎng)址不一致张峰，那么瀏覽器就會(huì)發(fā)出如下警告:
如果這張數(shù)字證書不是由受信任的機(jī)構(gòu)頒發(fā)的，那么瀏覽器發(fā)出警告為:
參考：
https://www.zhihu.com/question/52493697
http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
