快速了解公鑰、私鑰與證書

最近有需要了解這方面的知識，於是網上看了一些資料，這里記錄2個比較通俗易懂的介紹，對普通的加解密和整個http數據傳輸流程理解很有幫助。

轉載於：

作者：David Youd

翻譯：阮一峰

英文原文網址：http://www.youdzone.com/signature.html

中文翻譯網址：http://www.blogjava.net/yxhxj2006/archive/2012/10/15/389547.html

一次看懂 Https 證書認證

數字簽名是什么？

鮑勃有兩把鑰匙，一把是公鑰，另一把是私鑰。

鮑勃把公鑰送給他的朋友們----帕蒂、道格、蘇珊----每人一把。

蘇珊要給鮑勃寫一封保密的信。她寫完后用鮑勃的公鑰加密，就可以達到保密的效果。

鮑勃收信后，用私鑰解密，就看到了信件內容。這里要強調的是，只要鮑勃的私鑰不泄露，這封信就是安全的，即使落在別人手里，也無法解密。

鮑勃給蘇珊回信，決定采用"數字簽名"。他寫完后先用Hash函數，生成信件的摘要（digest）。

然后，鮑勃使用私鑰，對這個摘要加密，生成"數字簽名"（signature）。

鮑勃將這個簽名，附在信件下面，一起發給蘇珊。

蘇珊收信后，取下數字簽名，用鮑勃的公鑰解密，得到信件的摘要。由此證明，這封信確實是鮑勃發出的。

蘇珊再對信件本身使用Hash函數，將得到的結果，與上一步得到的摘要進行對比。如果兩者一致，就證明這封信未被修改過。

復雜的情況出現了。道格想欺騙蘇珊，他偷偷使用了蘇珊的電腦，用自己的公鑰換走了鮑勃的公鑰。此時，蘇珊實際擁有的是道格的公鑰，但是還以為這是鮑勃的公鑰。因此，道格就可以冒充鮑勃，用自己的私鑰做成"數字簽名"，寫信給蘇珊，讓蘇珊用假的鮑勃公鑰進行解密。

后來，蘇珊感覺不對勁，發現自己無法確定公鑰是否真的屬於鮑勃。她想到了一個辦法，要求鮑勃去找"證書中心"（certificate authority，簡稱CA），為公鑰做認證。證書中心用自己的私鑰，對鮑勃的公鑰和一些相關信息一起加密，生成"數字證書"（Digital Certificate）。

鮑勃拿到數字證書以后，就可以放心了。以后再給蘇珊寫信，只要在簽名的同時，再附上數字證書就行了。

蘇珊收信后，用CA的公鑰解開數字證書，就可以拿到鮑勃真實的公鑰了，然后就能證明"數字簽名"是否真的是鮑勃簽的。

下面，我們看一個應用"數字證書"的實例：https協議。這個協議主要用於網頁加密。

首先，客戶端向服務器發出加密請求。

服務器用自己的私鑰加密網頁以后，連同本身的數字證書，一起發送給客戶端。

客戶端（瀏覽器）的"證書管理器"，有"受信任的根證書頒發機構"列表。客戶端會根據這張列表，查看解開數字證書的公鑰是否在列表之內。

如果數字證書記載的網址，與你正在瀏覽的網址不一致，就說明這張證書可能被冒用，瀏覽器會發出警告。

如果這張數字證書不是由受信任的機構頒發的，瀏覽器會發出另一種警告。

TLS

傳輸層安全性協定 TLS（Transport Layer Security），及其前身安全套接層 SSL（Secure Sockets Layer）是一種安全協議，目的是為網際網路通信，提供安全及數據完整性保障。

如圖，TLS 在建立連接時是需要

1. 客戶端發送 ClientHello（包含支持的協議版本、加密算法和 隨機數A (Client random)）到服務端
2. 服務端返回 ServerHello、公鑰、證書、隨機數B (Server random) 到客戶端
3. 客戶端使用CA證書驗證返回證書無誤后。生成 隨機數C (Premaster secret)，用公鑰對其加密，發送到服務端
4. 服務端用 私鑰 解密得到 隨機數C (Premaster secret)，隨后根據已經得到的 隨機數ABC生成對稱密鑰（hello的時候確定的加密算法），並對需要發送的數據進行對稱加密發送
5. 客戶端使用對稱密鑰（客戶端也用隨機數ABC生成對稱密鑰）對數據進行解密。
6. 雙方手持對稱密鑰 使用對稱加密算法通訊

而這一流程 服務端的證書 是是至關重要的。

證書

證書用來證明公鑰擁有者身份的憑證

首先我們需要知道 證書是怎么來的。

數字證書一般由數字證書認證機構簽發，需要

• 申請者通過非對稱加密算法（RSA） 生成一對公鑰和密鑰，然后把需要的申請信息（國家，域名等）連同公鑰發送給 證書認證機構（CA）
• CA構確認無誤后通過消息摘要算法（MD5，SHA) 生成整個申請信息的摘要簽名M， 然后 把 簽名M和使用的摘要算法 用 CA自己的私鑰 進行加密

證書包含了

• 公鑰
• 證書擁有者身份信息
• 數字證書認證機構（發行者）信息
• 發行者對這份文件的數字簽名及使用的算法
• 有效期

證書的格式和驗證方法普遍遵循 X.509 國際標准。

證書認證機構（CA）

數字證書認證機構（英語：Certificate Authority，縮寫為CA），也稱為電子商務認證中心、電子商務認證授權機構，是負責發放和管理數字證書的權威機構，並作為電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。

其實任何個體/組織都可以成為CA（自簽證書），但是你發發布的證書客戶端是不信任的，也是就前文提及的需要權威。比如 Symantec、Comodo、Godaddy、Digicert。

客戶端信任這些CA，就會在其本地保持這些CA的 根證書（root certificate），根證書是CA自己的證書，是證書驗證鏈的開頭。
根證書沒有機構（已經是權威了）再為其做數字簽名，所以都是自簽證書。

CA會通過 中介證書（intermediate-certificate） 替代根證書的去做服務器端的證書簽名，確保根證書密鑰絕對不可訪問。

Godaddy 給出了解釋

What is an intermediate certificate?
https://sg.godaddy.com/help/what-is-an-intermediate-certificate-868

證書信任鏈

前文提到，在向CA 申請證書時是需要 CA的私鑰 去對整個證書的簽名摘要做非對稱加密的，也就是證書是可以通過 CA的公鑰 去解密得到證書的簽名摘要的。
當我們再次用 相同的摘要算法（證書里面有保存所使用的算法）對整個證書做簽名，如果得到的簽名和證書上的簽名是一致的，說明這個證書是可信任的。

同理，中介證書 也是可以被這樣的方式證明其可信任。這樣的一整個流程稱為 信任鏈（Chain of trust）。

就是我絕對相信你（A>B）；你絕對相信他（B>C）；等於我絕對相信他（A>C）

以下是整個流程：

1. 客戶端得到服務端返回的證書，通過讀取得到 服務端證書的發布機構（Issuer）
2. 客戶端去操作系統查找這個發布機構的的證書，如果是不是根證書就繼續遞歸下去 直到拿到根證書。
3. 用 根證書的公鑰 去 解密驗證 上一層證書的合法性，再拿上一層證書的公鑰去驗證更上層證書的合法性；遞歸回溯。
4. 最后驗證服務器端的證書是 可信任 的。