1.10　數字證書

數字證書是一種權威的電子證明，由權威公正的第三方證書頒發機構（CA）簽發，用來證明公鑰擁有者的身份。數字證書中包含了公鑰信息、擁有者身份信息，以及CA對這份文件的數字簽名，用以保證這份文件的整體內容正確無誤。數字證書被廣泛用于需要身份驗證和數據安全的領域，簡單來說就是數字證書能夠證明這個公鑰被誰擁有。數字證書主要用來保證信息保密、身份確認、不可否認性和數據完整性，常見的格式是X.509格式。

用戶想要獲得數字證書，應該先向CA提出申請，CA驗證申請者的身份后，為其分配一個公鑰并且與其身份信息綁定。CA為該信息進行簽名，作為數字證書的一部分，然后把整個數字證書發送給申請者。

當需要鑒別數字證書的真偽時，只需要用CA的公鑰對數字證書上的簽名進行驗證即可，驗證通過則證明數字證書有效。

1.10.1　數字證書結構

數字證書的結構一般采用X.509格式，X.509格式使用ASN.1（Abstract Syntax Notation One）抽象語法標記來表示。ASN.1是一種由國際標準組織（ISO/ITU-T）制定的標準，描述了一種對數據進行表示、編碼、傳輸和解碼的數據格式，用于實現平臺之間的互操作性。X.509格式的數字證書結構如圖1-4所示。

在X.509格式的數字證書中，各個字段含義如下。

? 版本：數字證書使用X.509規范的版本，目前普遍使用v3版本。

? 序列號：CA會為每個頒發的數字證書分配一個整數，作為數字證書的唯一標識。

? 簽名算法：CA頒發數字證書使用的簽名算法。

? 有效期：包含數字證書的起止日期。

? 主體名：該數字證書擁有者的名稱，如果與頒發者相同，則說明該數字證書是一個自簽名證書。

? 公鑰信息：對外公開的公鑰及所使用的公鑰生成算法。

? 擴展信息：通常包含數字證書的用法、證書吊銷列表（Certificate Revocation List，CRL）的發布地址等可選字段。

? 簽名：頒發者用私鑰對數字證書信息的簽名。

前文提到TLS協議已經廣泛地應用于瀏覽器中，我們在對網站進行瀏覽時，可以發現很多網站都采用HTTPS協議來提供對網站服務器的身份驗證。HTTPS協議經由HTTP進行通信，但利用SSL/TLS協議來加密數據包。我們可以通過找到采用HTTPS協議的網站查看網站證書來加深對數字證書的理解，圖1-5查看了Google網站的數字證書。

1.10.2　數字證書類型

數字證書根據用途的不同，有不同的分類。

自簽名證書：自簽名證書又稱根證書，是CA頒發給自己的證書，證書的頒發者和主體同名，也就意味著證書中的公鑰和用于驗證證書的密鑰是相同的。自簽名證書通常不會被廣泛信任，使用時可能會遇到系統軟件的安全警告。

如果軟件安裝自簽名證書則意味著對這個CA的信任，通常而言，自簽名證書已預先安裝在各種軟件（包括操作系統、瀏覽器、電郵軟件等）中，作為信任鏈的起點。自簽名證書一般來自公認可靠的政府機關、軟件公司（如Google、Let's Encrypt）、證書頒發機構公司（如VeriSign）等，各大軟件商通過嚴謹的核認程序才可以在不同的軟件中部署自簽名證書。由于部署程序復雜、費時，需要行政人員的授權及機構法人身份的核認，一經部署，自簽名證書有效期可能長達10年以上。某些企業可能會在內部計算機自行安裝企業自簽的自簽名證書，以支持內部網的企業級軟件，但是這些證書可能未被廣泛認可，只在企業內部適用。

中介證書：CA的一個重要任務是為客戶簽發證書，雖然廣泛認可的CA都已擁有自簽名證書，相對應的私鑰可以用來簽署其他證書，但因為密鑰管理和行政考慮，一般會先行簽發中介證書，才為客戶進行數字簽署。中介證書的有效期比自簽名證書短，并可能對不同類別的客戶進行不同的中介證書分工。

服務器證書：服務器通常以域名形式在互聯網上提供服務，服務器證書上主體的通用名稱就是相應的域名，相關機構名稱則寫在組織或單位一欄上。服務器證書（包括公鑰）和私鑰會安裝在服務器（如Apache）上，等待客戶端連接時協議加密細節。客戶端的軟件（如瀏覽器）會運行認證路徑驗證算法以確保安全，如果不能肯定加密通道是否安全（如證書上的主體名不對應網站域名、服務器使用了自簽名證書或加密算法不夠強），可能會警告用戶。

終端實體證書：不會被用作簽發其他證書的證書都可稱為終端實體證書。終端實體證書被用來在實際的軟件中部署或在創建加密通道時應用。

授權證書：授權證書又稱屬性證書，本身沒有公鑰，必須依附在一張有效的數字證書上才有意義，其用處是賦予相關擁有者簽發終端實體證書的權利。在某些情況下，如果只在短期內授予CA簽發權利，便可以不改變（縮短）該機構本身持有的證書的有效期。這種情況，類似于某人持有長達10年的護照，而只通過簽發短期入境簽證來個別賦予護照持有人額外權利。

1.10.3　數字證書編碼

數字證書在計算機中的表示方法有所不同，但是都是可以相互轉換的，常見的編碼格式為PKCS#12、DER和PEM。

PKCS標準是指由RSA Security設計和發布的一組公鑰加密標準。因此，RSA Security及其研究部門RSA Labs有義務促進公鑰技術的使用。為此，他們（從20世紀90年代初開始）開發了PKCS標準，并保留了對PKCS標準的控制權，宣布他們會在自己認為必要的時候進行改變或改進，因此，PKCS標準在重要意義上并不是真正的行業標準，盡管名稱如此。對于PKCS標準，常見的是標準PKCS#12，其中#12是標準編號，文件后綴是P12。

DER（可分辨編碼規則）是一種用于存儲X.509證書文件的流行編碼標準。ASN.1的可分辨編碼規則是根據X.509規范對BER編碼的約束得出的國際標準。DER編碼是有效的BER編碼。DER編碼與BER編碼相以，只是刪除了一個發送者的選項。例如，在BER編碼中，布爾值true可以用255種方式編碼，而在DER編碼中，只有一種方法可以編碼布爾值true。DER編碼的完整規范在RFC 1421中。

X.509證書文件最常用的編碼方案是PEM（隱私增強郵件）編碼。PEM編碼的完整規范在RFC 1421中。在X.509證書文件上進行PEM編碼的想法非常簡單：使用Base64編碼對內容進行編碼。編碼后的文件后綴通常為PEM，將Base64編碼輸出括在兩行之間：“----- BEGIN CERTIFICATE -----”和“----- END CERTIFICATE -----”，下面的例子是PEM編碼的X.509證書結構示例。

DER編碼的X.509證書文件是二進制文件，無法使用文本編輯器查看，但幾乎所有應用程序都支持DER編碼的證書文件。DER編碼的證書文件的文件擴展名為“.cer”“.der”“.crt”。

1.10.4　簡單應用

假設一個簡單的場景，Alice需要通過銀行轉給Bob一筆錢，使用之前的密碼學知識就可以保證這個過程的安全可靠。

可以通過對稱加密的方式，生成公私鑰對，其中，公鑰a可以公開，作為銀行賬戶；私鑰b作為賬戶密碼，不予公開。

當Alice向Bob轉100元時，可以在計算機中向銀行發送這樣一條請求<form:Alice, to:Bob, value: 100>，表示Alice向Bob轉賬100元。如果整個過程不加驗證，被黑客發現這個漏洞后就可以不斷地重復這個過程，直到把Alice的賬戶余額轉空。

為了表示這個交易確實是由Alice發出的，可以增加Alice的簽名，用Alice的公鑰a所對應的私鑰對這個請求簽名。整個請求就成了{<form:Alice, to:Bob, value: 100>, signature: foo}，這樣銀行收到這筆交易后，就可以用Alice的公鑰，也就是a對交易進行驗證，判斷是不是由Alice發出的。

但是由于Alice太過富有，轉賬成了{<form:Alice, to:Bob, value: 1000000000.002>, signature: bar}，交易請求<form:Alice, to:Bob, value: 1000000000.002>體積太大，簽名算法對大量數據的輸入簽名效率不高，這個時候，就可以采用消息摘要算法，減少計算簽名輸入的長度的工作量，如首先采用哈希算法計算Hash（<form:Alice, to:Bob, value: 1000000000.002>）=baz，然后對摘要baz簽名即可。當銀行收到這筆交易時，同樣先對交易計算哈希值，再驗證簽名即可。