簡介

和阮一峰一樣，我也是 ：對"數字簽名"（digital signature）和"數字證書"（digital certificate）到底是什么有些模糊。仔細閱讀之后記錄一下。

數字簽名最初的目的是解決內容加密和身份鑒別的。

過程是：發件人把發件的內容做摘要，然后用私鑰加密。把內容，摘要、給收件人，收件人用自己的公鑰解密，證明信件是受到信任的發件人發的。然后用同樣的算法對內容做摘要和收到的摘要對比，發現一致。證明沒有修改過。

但是，壞人來了！

壞人入侵了你的郵箱（也可以理解為電腦、手機），把發件人發出的公鑰改成了自己的公鑰，這樣，壞人呢用自己的私鑰加密的內容發送給你，你也可以解密，也可以『假裝』認為也是 我信任的人發送的。

所以數字證書來了，數字證書解決的就是 公鑰受信任的問題！！！

它可以用來加密連接和加密內容！

數字證書如何頒發的

數字證書如何頒發的.png

證書頒發

1/ 首先撰寫證書的元信息：簽發人(Issuer)、地址、簽發時間、過期失效等；當然，這些信息中還包含證書持有者(owner)的基本信息，例如owner的DN(DNS Name，即證書生效的域名)，owner的公鑰等基本信息。
2/ 通過通用的Hash算法將信息摘要提取出來；
3/ Hash摘要通過Issuer(CA)私鑰進行非對稱加密，生成一個簽名密文；
4/ 將簽名密文attach到文件證書上，使之變成一個簽名過的證書。
也就是說，數字證書包含了 證書所有人信息以及證書所有人信息進過摘要并且經過CA 進行非對稱加密之后的密文的這么一個數字文件。

證書的驗證

1/ 客戶端、瀏覽器獲得之前簽發的證書；
2/ 將其解壓后分別獲得“元數據”和“簽名密文”；
3/ 將同樣的Hash算法應用到“元數據”獲取摘要；
4/ 將密文通過Issuer(CA)的公鑰（非對稱算法，私鑰加密，公鑰解密）解密獲得同樣的摘要值。
5/ 比對兩個摘要，如果匹配，則說明這個證書是被CA驗證過合法證書，里面的公鑰等信息是可信的。

整個過程如下：

數字證書驗證.png

也就是說數字證書驗證的時候，使用證書中包含的證書所有者信息、經過CA加密過的密文、CA的公鑰等來驗證。

說到這，就知道了下面受信任的根證書，到底是作何用的了！！！

受信任的根證書

數字證書的分類

證書有很多類型，首先分為三種認證級別。

1/ 域名認證（Domain Validation）：最低級別認證，可以確認申請人擁有這個域名。對于這種證書，瀏覽器會在地址欄顯示一把鎖。
2/ 公司認證（Company Validation）：確認域名所有人是哪一家公司，證書里面會包含公司信息。
3/ 擴展認證（Extended Validation）：最高級別的認證，瀏覽器地址欄會顯示公司名。

按照覆蓋范圍分類

1/ 單域名證書：只能用于單一域名，foo.com的證書不能用于www.foo.com
2/ 通配符證書：可以用于某個域名及其所有一級子域名，比如*.foo.com的證書可以用于foo.com，也可以用于www.foo.com
3/ 多域名證書：可以用于多個域名，比如foo.com和bar.com

證書鏈

HTTPS的核心就是證書鏈，證書鏈的“信任”核心是CA。

如下圖，在瀏覽器打開baidu.com，會發現它使用的是https連接，有一個綠色的小鎖。

Paste_Image.png

baidu使用的HTTPS證書，除了HTTPS使用的 baidu.com 證書，向上還有兩級證書，證書有3類：
1/ end-user ：baidu.com 包含用來加密傳輸數據的公鑰的證書，是HTTPS中使用的證書
2/ intermediates：CA用來認證公鑰持有者身份的證書，即確認HTTPS使用的end-user證書是屬于baidu.com的證書。這類intermediates證書甚至可以有很多級。
中間證書的含義：
https://sg.godaddy.com/en/help/what-is-an-intermediate-certificate-868
3/ root：用來認證intermediates證書是合法證書的證書。
簡單來說，end-user證書上面幾級證書都是為了保證end-user證書未被篡改，保證是CA簽發的合法證書，進而保證end-user證書中的公鑰未被篡改。

除了end-user之外，證書被分為root Certificates和intermediates Certificates。相應地，CA也分了兩種類型：root CAs 和 intermediates CAs。首先，CA的組織結構是一個樹結構，一個root CAs下面包含多個intermediates CAs，而intermediates又可以包含多個intermediates CAs。root CAs 和 intermediates CAs都可以頒發證書給用戶，頒發的證書分別是root Certificates和intermediates Certificates，最終用戶用來認證公鑰的證書則被稱為end-user Certificates。

證書鏈驗證

如何保證，end user使用的公鑰是合法的呢？

Paste_Image.png

參考：https://www.pianyissl.com/support/page/10

數字證書結構

最常用的 是 X.509證書的結構
1、X.509證書基本部分
1.1. 版本號.
標識證書的版本（版本1、版本2或是版本3）。

1.2. 序列號
標識證書的唯一整數，由證書頒發者分配的本證書的唯一標識符。

1.3. 簽名
用于簽證書的算法標識，由對象標識符加上相關的參數組成，用于說明本證書所用的數字簽名算法。例如，SHA-1和RSA的對象標識符就用來說明該數字簽名是利用RSA對SHA-1雜湊加密。

1.4. 頒發者
證書頒發者的可識別名（DN）。

1.5. 有效期
證書有效期的時間段。本字段由”Not Before”和”Not After”兩項組成，它們分別由UTC時間或一般的時間表示（在RFC2459中有詳細的時間表示規則）。

1.6. 主體
證書擁有者的可識別名，這個字段必須是非空的，除非你在證書擴展中有別名。

1.7. 主體公鑰信息
主體的公鑰（以及算法標識符）。

1.8. 頒發者唯一標識符
標識符—證書頒發者的唯一標識符，僅在版本2和版本3中有要求，屬于可選項。

1.9. 主體唯一標識符
證書擁有者的唯一標識符，僅在版本2和版本3中有要求，屬于可選項。

2、X.509證書擴展部分
可選的標準和專用的擴展（僅在版本2和版本3中使用），擴展部分的元素都有這樣的結構：

Extension ::= SEQUENCE {
extnID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
extnValue OCTET STRING }
extnID：表示一個擴展元素的OID

critical：表示這個擴展元素是否極重要

extnValue：表示這個擴展元素的值，字符串類型。

擴展部分包括：

2.1. 發行者密鑰標識符
證書所含密鑰的唯一標識符，用來區分同一證書擁有者的多對密鑰。

2.2. 密鑰使用
一個比特串，指明（限定）證書的公鑰可以完成的功能或服務，如：證書簽名、數據加密等。

如果某一證書將 KeyUsage 擴展標記為“極重要”，而且設置為“keyCertSign”，則在 SSL 通信期間該證書出現時將被拒絕，因為該證書擴展表示相關私鑰應只用于簽寫證書，而不應該用于 SSL。

2.3. CRL分布點
指明CRL的分布地點。

2.4. 私鑰的使用期
指明證書中與公鑰相聯系的私鑰的使用期限，它也有Not Before和Not After組成。若此項不存在時，公私鑰的使用期是一樣的。

2.5. 證書策略
由對象標識符和限定符組成，這些對象標識符說明證書的頒發和使用策略有關。

2.6. 策略映射
表明兩個CA域之間的一個或多個策略對象標識符的等價關系，僅在CA證書里存在。

2.7. 主體別名
指出證書擁有者的別名，如電子郵件地址、IP地址等，別名是和DN綁定在一起的。

2.8. 頒發者別名
指出證書頒發者的別名，如電子郵件地址、IP地址等，但頒發者的DN必須出現在證書的頒發者字段。

2.9. 主體目錄屬性
指出證書擁有者的一系列屬性。可以使用這一項來傳遞訪問控制信息。

證書的驗證

方法1

Paste_Image.png

結果如下，有類似 verify error:這樣的信息肯定是不對的。屬于服務器配置問題。

depth=0 /C=CN/ST=\xE6\xB1\x9F\xE8\x8B\x8F/L=\xE8\x8B\x8F\xE5\xB7\x9E/OU=\xE4\xB8\xAD\xE7\xA7\xBB\xEF\xBC\x88\xE8\x8B\x8F\xE5\xB7\x9E\xEF\xBC\x89\xE8\xBD\xAF\xE4\xBB\xB6\xE6\x8A\x80\xE6\x9C\xAF\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=CN/ST=\xE6\xB1\x9F\xE8\x8B\x8F/L=\xE8\x8B\x8F\xE5\xB7\x9E/OU=\xE4\xB8\xAD\xE7\xA7\xBB\xEF\xBC\x88\xE8\x8B\x8F\xE5\xB7\x9E\xEF\xBC\x89\xE8\xBD\xAF\xE4\xBB\xB6\xE6\x8A\x80\xE6\x9C\xAF\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=CN/ST=\xE6\xB1\x9F\xE8\x8B\x8F/L=\xE8\x8B\x8F\xE5\xB7\x9E/OU=\xE4\xB8\xAD\xE7\xA7\xBB\xEF\xBC\x88\xE8\x8B\x8F\xE5\xB7\x9E\xEF\xBC\x89\xE8\xBD\xAF\xE4\xBB\xB6\xE6\x8A\x80\xE6\x9C\xAF\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8
verify error:num=21:unable to verify the first certificate
verify return:1
read from 0x7fa415e00170 [0x7fa416806600] (5 bytes => 5 (0x5))
0000 - 16 03 01 00 04 .....
read from 0x7fa415e00170 [0x7fa416806605] (4 bytes => 4 (0x4))
0000 - 0e .
0004 - <SPACES/NULS>

方法2
https://tools.keycdn.com/ssl

客戶端使用

沒經過 CA 認證的自簽證書的驗證 和 CA 認證的證書鏈的驗證方式是一樣，不同點在不可信錨點的證書類型不一樣而已：前者的錨點是自簽的需要被打包進 App 用于驗證，后者的錨點可能本來就存在系統之中了。

安卓端使用：http://xhrwang.me/2015/06/06/https-and-android.html

參考：http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html