數字證書和 CA
綜合使用對稱加密、非對稱加密和摘要算法，我們已經實現了安全的四大特性，是不是已經完美了呢？
不是的，這裏還有一個“公鑰的信任”問題。
因爲誰都可以發佈公鑰，我們還缺少防止黑客僞造公鑰的手段，也就是說，怎麼來判斷這個公鑰就是你或者某寶的公鑰呢？
http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
1.zfb 生成自己的公鑰，私鑰 ，公鑰掛在網站上任人下載
2.小明下載了 zfb公鑰,利用這個公鑰 加密一段信息 data1(生成訂單請求)爲data1_enc 發送給zfb
3.zfb到加密信息data1_enc 用自己的私鑰解開爲data1
處理相關數據後 計算出要處理的業務數據data2(通知小明這個訂單的支付情況),
用hash算法對data2生成摘要data2_digest
用自己的私鑰加密摘要加密爲 data2_digest_enc 即爲數字簽名signature
然後把data2+data2_digest_enc 發送給小明
4.小明收到data2+data2_digest_enc,用zfb的公鑰解密data2_digest_enc
解開爲data2_digest由此證明，信息是zfb發給自己的
然後對data2使用hash函數得到的結果與data2_disget比較，如果1致說明信息是完整的沒有被篡改過
-------------------------------------------------------------
但是有1天小明被小灰把他之前獲取的zfb公鑰偷偷替換爲小灰自己的公鑰了
(也有可能是小灰把支付寶網站攻擊了換成自己的公鑰，然後小明去下載其實下載的是小灰的公鑰而不是zfb的)
小明這邊有人(其實就是小灰)下單後把數據用小灰的公鑰加密，發給zfb，
當然支付寶用自己的私鑰解不開，
小灰途中獲取到小明發給支付寶的數據，用自己的私鑰解密了，
在沒扣款的情況下，通知小明支付成功，小明發貨後，發現賬戶裏沒收到這筆訂單的錢
-------------------------------------------------------------------------
小明發現異常後,決定找信任機構CA,讓zfb帶着他的公鑰去CA 讓CA爲他做公鑰認證
CA用自己的私鑰把zfb的公鑰和一些他的其它信息加密
生成數字證書
之後zfb給小明發消息時 連帶他的數字證書一起發過去
小明收到消息後,用CA的公鑰解開證書裏的信息獲取到zfb真實的公鑰
現在唯一的問題就是CA是可信的
我們可以用類似密鑰交換的方法來解決公鑰認證問題，用別的私鑰來給公鑰簽名，顯然，這又會陷入“無窮遞歸”。但這次實在是“沒招”了，要終結這個“死循環”，就必須引入“外力”，找一個公認的可信第三方，讓它作爲“信任的起點，遞歸的終點”，構建起公鑰的信任鏈。這個“第三方”就是我們常說的 CA（Certificate Authority，證書認證機構）
它就像網絡世界裏的公安局、教育部、公證中心，具有極高的可信度，由它來給各個公鑰簽名，用自身的信譽來保證公鑰無法僞造，是可信的。
CA 對公鑰的簽名認證也是有格式的，不是簡單地把公鑰綁定在持有者身份上就完事了，還要包含序列號、用途、頒發者、有效時間等等，把這些打成一個包再簽名，完整地證明公鑰關聯的各種信息，形成“數字證書”（Certificate）。
知名的 CA 全世界就那麼幾家，比如 DigiCert、VeriSign、Entrust、Let’s Encrypt 等，它們簽發的證書分 DV、OV、EV 三種，區別在於可信程度。DV 是最低的，只是域名級別的可信，背後是誰不知道。EV 是最高的，經過了法律和審計的嚴格覈查，可以證明網站擁有者的身份（在瀏覽器地址欄會顯示出公司的名字，例如 Apple、GitHub 的網站）。
不過，CA 怎麼證明自己呢？這還是信任鏈的問題。
小一點的 CA 可以讓大 CA 簽名認證，但鏈條的最後，也就是 Root CA，就只能自己證明自己了，這個就叫“自簽名證書”（Self-Signed Certificate）或者“根證書”（Root Certificate）。你必須相信，否則整個證書信任鏈就走不下去了
有了這個證書體系，操作系統和瀏覽器都內置了各大 CA 的根證書，上網的時候只要服務器發過來它的證書，就可以驗證證書裏的簽名，順着證書鏈（Certificate Chain）一層層地驗證，直到找到根證書，就能夠確定證書是可信的，從而裏面的公鑰也是可信的。
實驗環境裏使用的證書是“野路子”的自簽名證書（在 Linux 上用 OpenSSL 命令行簽發），肯定是不會被瀏覽器所信任的，所以用 Chrome 訪問時就會顯示成紅色，標記爲不安全。但你只要把它安裝進系統的根證書存儲區裏，讓它作爲信任鏈的根，就不會再有危險警告。
證書體系的弱點
證書體系（PKI，Public Key Infrastructure）雖然是目前整個網絡世界的安全基礎設施，但絕對的安全是不存在的，它也有弱點，還是關鍵的“信任”二字。
如果 CA 失誤或者被欺騙，簽發了錯誤的證書，雖然證書是真的，可它代表的網站卻是假的。
還有一種更危險的情況，CA 被黑客攻陷，或者 CA 有惡意，因爲它（即根證書）是信任的源頭，整個信任鏈裏的所有證書也就都不可信了。
這兩種事情並不是“聳人聽聞”，都曾經實際出現過。所以，需要再給證書體系打上一些補丁。
針對第一種，開發出了 CRL（證書吊銷列表，Certificate revocation list）和 OCSP（在線證書狀態協議，Online Certificate Status Protocol），及時廢止有問題的證書。
對於第二種，因爲涉及的證書太多，就只能操作系統或者瀏覽器從根上“下狠手”了，撤銷對 CA 的信任，列入“黑名單”，這樣它頒發的所有證書就都會被認爲是不安全的
- 摘要算法用來實現完整性，能夠爲數據生成獨一無二的“指紋”，常用的算法是 SHA-2
- 數字簽名是私鑰對摘要的加密，可以由公鑰解密後驗證，實現身份認證和不可否認
- 公鑰的分發需要使用數字證書，必須由 CA 的信任鏈來驗證，否則就是不可信的
- 作爲信任鏈的源頭 CA 有時也會不可信，解決辦法有 CRL、OCSP，還有終止信任
保密性：靠混合加密解決，非對稱加密實現對稱加密祕鑰傳遞，對稱加密實現內容加密。
完整性：靠摘要算法解決。
身份認證：靠數字證書解決，數字證書因爲CA機構的信任變成一個完整信任鏈條，從而實現通過數字證書證明了對方真實身份，但注意身份真實也可能是掛羊頭賣狗肉，是一個壞人，所以，有了CRL、OCSP，還有終止信任。
不可否認：靠數字簽名解決，內容摘要算法得到摘要，私鑰加密摘要，對方使用對應公鑰解密，得到摘要，再和自己得到的服務器提供的原文摘要對比，一致說明這個內容就是原服務器提供的，由證書說明了服務器的身份。
服務器返回證書鏈（不包括根證書，根證書預置在瀏覽器中），
然後瀏覽器就可以使用信任的根證書（根公鑰）解析證書鏈的根證書得到一級證書的公鑰+摘要驗籤，
然後拿一級證書的公鑰解密一級證書拿到二級證書的公鑰和摘要驗籤，
再然後拿二級證書的公鑰解密二級證書得到服務器的公鑰和摘要驗籤，驗證過程就結束了
數字簽名和數字證書只用於TSL/SSL的握手階段，主要是保證服務器的公鑰能夠正確地傳給瀏覽器（不被中間人僞裝發送假的公鑰）
具體流程大概是：
- 1.服務器去CA機構申請證書，證書中包含了要發給客戶端的公鑰、簽發者、到期時間等等信息。
如果這樣簡單地把證書發給瀏覽器，中間人可以輕鬆地修改成自己的公鑰，之後的通信就是不安全的了
於是需要一定的加密手段，這裏的做法就是使用數字簽名：將證書的信息利用摘要算法計算出摘要之後，用CA的祕鑰進行加密，生成數字簽名
- 2.服務器將數字證書和數字簽名一起發給瀏覽器，因爲有數字簽名，所以數字證書無法被中間人做修改（修改之後生成的數字簽名和原數字簽名不一致了），瀏覽器拿到數字證書之後，去本地的信任機構中查詢到對應的機構，利用其公鑰解密數字簽名，驗證證書是否有被修改過。
這一步就保證了瀏覽器獲取到的公鑰一定是正確的。 - 3.公鑰正確地傳給瀏覽器之後，接着就是協商對稱加密的密鑰，然後通信等等