細讀HTTPS -- 公鑰基礎設施PKI

細讀HTTPS – 公鑰基礎設施PKI

PKI（public key infrastructure）的目標就是實現不同成員在不見面的情況下進行安全通信，我們當前採用的模型是基於可信的第三方機構，也就是證書頒發機構（certification authority或certificate authority，CA）簽發的證書。

下面就參照這張圖分別來介紹下各個部分的含義.

訂閱人

訂閱人（或者說最終實體）是指那些需要證書來提供安全服務的團體。互聯網方面主要是指網絡公司。

證書

證書是一個包含公鑰、訂閱人相關信息以及證書頒發者數字簽名的數字文件，，也就是一個讓我們可以交換、存儲和使用公鑰的殼。因此，證書成爲了整個PKI體系的基礎組成元素。
證書的生命週期在訂閱人準備證書籤名申請（certificate signing request，CSR）文件，並將它提交給所選CA的時候就開始了。CSR文件的主要目的是攜帶公鑰信息，並且證明訂閱人擁有對應的私鑰（通過簽名來證明）。
不同類型的證書申請：

域名驗證（domain validated，DV）證書

DV證書需要CA驗證訂閱人對域名的所有權之後才能進行簽發。

組織驗證（organization validated，OV）證書

OV證書會對身份和真實性進行驗證。直到採用了Baseline Requirements之後，OV證書的驗證流程才標準化起來，但是在如何簽發OV證書以及如何將這些信息編碼到證書中等方面，依舊存在很多前後不一致的情況。

擴展驗證（extended validation，EV）證書

EV證書以更加嚴格的要求驗證身份和真實性。它是爲了解決OV證書缺乏的前後一致性而引入的，所以EV證書的驗證流程非常詳細，幾乎不會出現前後不一致的情況。

DV證書的簽發是全自動的，所以非常快，它的簽發時間主要取決於DNS管理員確認郵件所需的時間；而EV證書則相反，可能需要幾天甚至幾周才能拿到。

證書字段

• 版本：證書一共有3個版本號，分別用0、1、2編碼表示版本1、版本2和版本3。版本1只支持簡單的字段，版本2增加了兩個標識符（新增的字段），而版本3則增加了擴展功能。現在大部分的證書都採用版本3的格式。
• 序列號：在一開始，序列號只要是正整數即可，是每個CA用來唯一標識其所簽發的證書。但是在出現了針對證書籤名的預選前綴攻擊之後，序列號增加了更多的要求來防止此類攻擊；現在序列號需要是無序的（無法被預測）而且至少包括20位的熵。
• 簽名算法：這個字段指明證書籤名所用的算法，這樣才能被證書籤名保護。
• 頒發者：頒發者（issuer）字段包括了證書頒發者的可分辨名稱（distinguished name，DN），這個字段比較複雜，根據不同的實體會包含許多部分。舉例來說，Verisign根證書的可分辨名稱是/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority；它包括了國家、組織和組織單位三個部分。
• 有效期：證書的有效期包括開始日期和結束日期，在這段時間內證書是有效的。
• 使用者：使用者是實體的可分辨名稱，和公鑰一起用於證書的簽發。
• 公鑰：這個字段包含了公鑰，以使用者公鑰信息（subject public-key info）結構呈現（主要是算法ID，可選參數以及公鑰本身）。
  另外證書有可擴展的字段…

證書鏈

在大多數情況下，僅僅有最終實體證書是無法進行有效性驗證的，所以在實踐中，服務器需要提供證書鏈才能一步步地最終驗證到可信根證書，如圖下圖所示。證書鏈的使用可能出於安全、技術和管理等方面的原因。

證書吊銷

當出現私鑰泄露或者不再需要使用的時候，我們就需要吊銷證書。但是這裏存在誤用的風險。吊銷協議和流程的設計是爲了確保證書是有效的，否則就需要將吊銷情況通知信賴方。現在有下面兩種證書吊銷標準。

證書吊銷列表 - CRL

證書吊銷列表（certificate revocation list，CRL）是一組未過期、但是卻已經被吊銷的證書序列號列表，CA維護了一個或多個這樣的列表。每一張證書都需要在CRL分發點（CRLdistribution point）擴展中包含對應的CRL地址。CRL最大的問題在於它越來越大，實時查詢起來會非常慢。

在線證書狀態協議 - OCSP

在線證書狀態協議（online certificate status protocol，OCSP）允許信賴方獲得一張證書的吊銷信息。OCSP服務器通常稱爲OCSP響應程序，OCSP響應程序的地址編碼在頒發機構信息訪問（authority information access，AIA）證書擴展中。OCSP支持實時查詢並且解決了CRL最大的缺點，但是並沒有解決所有的吊銷問題：因爲OCSP的使用帶來了性能、隱私方面的問題和新的漏洞。其中一部分問題可以通過OCSP stapling技術來解決，它允許服務器在TLS握手的過程中直接嵌入OCSP響應。

信賴方

信賴方一般是指瀏覽器。信賴方爲了能夠驗證證書，必須收集信任的所有根CA證書。大多數的操作系統都提供一個根證書庫，從而在一開始啓動的時候就能夠建立信任。幾乎所有的軟件開發者都重用了底層操作系統提供的根證書庫，唯一的例外是Mozilla，爲了保證不同平臺的兼容性，它維護了自己的根證書庫。

• Apple：Apple維護的根證書庫主要是給iOS和OS X平臺使用②，如果某個CA希望加入到Apple的根證書庫裏面的話，就需要通過權威機構審計並且對Apple的客戶有商業價值。
• Chrome：在Linux上，Chrome使用Mozilla的根證書庫（通過NSS網絡庫），除此之外Chrome都是依賴操作系統提供的證書庫。
• Microsoft：Microsoft維護的根證書庫主要是給Windows桌面版、服務器版以及移動手機平臺使用。④同樣，如果要加入，需要至少一年的審計並且提供一份能夠爲Microsoft的用戶羣帶來商業價值的說明。
• Mozilla：Mozilla爲自己的產品維護了一個公開透明的根證書庫⑤並且大部分Linux版本都使用Mozilla的根證書庫。

證書頒發機構 – CA

證書頒發機構（certification authority，CA）是當前互聯網信任模型最重要的部分，他們可以簽發任何域名的證書，所以是非常權威的。表面上看來似乎是一門穩賺的生意，前提是你的根證書要內置到儘可能多的設備中。