證書可以理解爲簽發方信息、擁有者信息、公鑰以及簽名（由簽發方私鑰簽名）的集合（當然還有額外信息）。校驗證書是否可信，實際就是檢驗該證書是否是由合法的簽發方簽發，驗證的方法就是首先通過簽發方信息找到對應的簽發方證書，利用簽發方證書中的公鑰去校驗簽名是否正確。
從上述驗證方法可以看出，實際上證書是否可信是由其簽發方的證書來進行校驗的，而簽發方的證書的可信是由上一層簽發方的證書來校驗的，如此就形成一條證書鏈，而最頂層的就是常說的根證書。此外有也許會問如果瀏覽器中找不到簽發方證書怎麼辦？而且簽發方確認是可信的，此時在TLS協商的時候，可以下發證書鏈。
隨便搜一下TLS證書，會出現一大堆關鍵字：X.509, p12, pfx, pkcs, pem, csr, cer, crt, jks, crl等，這麼繁雜一下就讓人想從入門到放棄了，不過還是耐心梳理一下。
（一）X.509
X.509就是一個廣泛應用的數字證書標準，簡單來說就是定義了數字證書裏面包含哪些字段，如何存儲，可以參照一下RFC5280；協議中定義的參數都是採用DER編碼(X.690)，DER編碼可以理解爲一種TLV（Tag Length Value）格式編碼。
以一個實際的證書內容爲例，如下所示：
Certificate:
Data:
Version: 3 (0x2) //表示爲X509 v3版本證書
Serial Number: 1 (0x1) //序列號，簽發時需保證同一簽發方所簽發的每個證書都一個唯一的Serial Number
Signature Algorithm: sha256WithRSAEncryption //簽名算法，先進行SHA256摘要後，使用簽發方私鑰進行RSA加密
Issuer: C=CN, ST=JS, L=NJ, O=Dreamer, OU=Dreamer, CN=Dreamer //簽發方DN(Distingushed Name)，見後續說明
Validity //證書有效期
Not Before: Jul 29 14:02:13 2018 GMT
Not After : Jul 26 14:02:13 2028 GMT
Subject: C=CN, ST=JS, O=Dreamer, OU=JM, CN=*.dreamer.com //證書擁有方DN(Distingushed Name)
Subject Public Key Info: //證書公鑰信息
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:c5:b8:68:a2:9c:bd:11:0c:83:34:a2:97:a5:8e:
72:75:2a:bc:f4:75:fc:d0:a3:47:7d:e4:6b:4f:ed:
dd:79:7c:0f:ce:6e:e7:d2:7d:10:cd:e8:07:56:34:
58:e3:2b:2e:c9:e3:7f:ae:27:2d:f7:a3:17:6f:dd:
65:d7:f8:4f:d0:be:9c:3b:9b:ea:ed:86:d2:19:67:
81:60:53:64:c9:d1:be:17:7d:5d:7f:cc:58:1d:b6:
e1:51:0d:ba:32:ac:4d:73:a4:fc:8f:6a:79:f9:44:
25:03:b6:1c:3e:0f:e9:b8:36:b1:07:07:59:54:40:
d7:2c:52:ab:68:fe:ed:e2:6f
Exponent: 65537 (0x10001)
X509v3 extensions: //v3版本擴展信息
X509v3 Basic Constraints:
CA:FALSE //表示證書擁有方是否是CA機構，可簽發證書，如爲True，則還可以添加一個pathLengthConstraint來顯示簽發鏈的長度
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier: //證書擁有方密鑰ID，對於CA: TRUE時需要加入此擴展
67:30:EE:FB:39:A4:92:56:9C:1A:E8:94:10:A4:3B:EA:EC:2E:04:9E
X509v3 Authority Key Identifier: //證書籤發方所對應密鑰ID，用於簽發方的公鑰查找（特別是存在多個密鑰時）
DirName:/C=CN/ST=JS/L=NJ/O=Dreamer/OU=Dreamer/CN=Dreamer
serial:A0:09:E3:A9:D2:C1:86:7C
X509v3 Subject Alternative Name: //證書擁有方的別名，此處用戶多域名證書的簽發
DNS:*.example.com, DNS:*.jm.com
Signature Algorithm: sha256WithRSAEncryption //證書籤名信息
91:db:9b:0c:9b:6e:68:24:d3:2f:3a:67:b5:c0:6c:f0:c8:4c:
f8:87:86:93:eb:fc:dc:ef:dc:7b:2e:2c:0e:7b:52:23:4d:de:
d9:69:a8:ee:ae:aa:14:04:ca:1a:03:87:fe:11:60:fe:16:8f:
87:9d:9e:d0:3a:be:33:03:f6:25:8a:10:37:f8:90:9d:67:5c:
36:a6:1e:3c:59:d9:8f:eb:22:0e:f7:3c:7d:47:10:9b:0b:03:
f0:8c:70:b0:3c:40:c6:5d:cc:6b:ba:40:ce:89:04:c7:3c:be:
af:bd:1d:94:6b:83:39:29:74:de:12:fc:63:0d:0f:39:31:3b:
48:fd
除了上述的註釋說明外，需要補充的幾點如下：
Subject和Issuer均爲DN格式，常見格式：C=國家, ST=省市, L=區縣市, O=組織機構, OU=組織單位, CN=通用名稱。
DN是證書鏈查找的關鍵，驗證是會根據Issuer的DN去匹配簽發方的證書，具體的匹配方法是比較DN的數量以及各DN參數值，相對來說還是比較嚴格的
DN中的CN通用名稱一般表現爲域名，如需支持子域名，例如abc.server.com, bcd.server.com，可使用泛域名形式*.server.com
Subject Alternative Name擴展字段可用於多域名證書，後續將會具體介紹多域名證書的簽發。
（二）證書編碼格式（DER&PEM）
X.509中說明證書各個字段編碼均適用DER格式進行編碼，最終實際上整個證書就是一個純二進制格式文件，那PEM編碼又是什麼格式呢？
按照網上普遍說法，X.509有DER和PEM兩種編碼格式，其實這種說法個人認爲有點歧義，實際上這兩種編碼格式並不在一個層面上。前面說過DER一種純二進制TLV格式的編碼協議，那PEM是否也是一種類似TLV的鍵值型的編碼格式呢？其實PEM並沒有去處理X.509的內部參數，而是在X.509進行DER編碼之後，對二進制數據進行了BASE64編碼，然後加上文件頭尾即可，如下所示
-----BEGIN CERTIFICATE-----
MIICMTCCAZoCCQCgCeOp0sGGfDANBgkqhkiG9w0BAQsFADBdMQswCQYDVQQGEwJD
TjELMAkGA1UECAwCSlMxCzAJBgNVBAcMAk5KMRAwDgYDVQQKDAdEcmVhbWVyMRAw
DgYDVQQLDAdEcmVhbWVyMRAwDgYDVQQDDAdEcmVhbWVyMB4XDTE4MDcyODE1NTEx
NFoXDTI4MDcyNTE1NTExNFowXTELMAkGA1UEBhMCQ04xCzAJBgNVBAgMAkpTMQsw
CQYDVQQHDAJOSjEQMA4GA1UECgwHRHJlYW1lcjEQMA4GA1UECwwHRHJlYW1lcjEQ
MA4GA1UEAwwHRHJlYW1lcjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwjDr
aM8SubYIN/dqmJLCHYWBet7yQ80H3VPcbeYPja2Fq1VPb0vKMXzfd8BdaJ3roown
ZCJlfxCFPqN/z8/a0BS+ukmknOcYeYoN+vpVg9Oq3fH0iy+TRg+ydOVwmyAXJk0D
GS7WFjHv6DYRlH/xgKXuHGXwytNpQHZdDzq6bV0CAwEAATANBgkqhkiG9w0BAQsF
AAOBgQCaoAdYiWpGKcvc89ZPwL/Zd0KgSLnAln/38a69N5LqtDgWD9a6PDjHHmTF
/cN/p8hJ3LdEXfPGtFj06+KaG6OVOAo5RSqOHc5DcMs1nAImqIAuLt2rOCmsY+li
T9tweI2raih6OMTKAeIW5m46T28oPlNgeEMy2Uj2CevS6tCaLQ==
-----END CERTIFICATE-----
具體區分DER還是PEM也很簡單，打開有亂碼的是DER格式文件，打開類似上面格式的就是PEM格式證書文件。
（三）證書相關擴展名
擴展名是比較容易誤導人的地方，除了.der或.pem後綴外，還有以下常見後綴：
crt：常見於*nix系統，大多是PEM編碼，也可能是DER編碼
cer：常見於Windows系統，大多是DER編碼，也可能是PEM編碼
key：用戶存放密鑰信息，和證書一樣，可能是DER編碼，也可能是PEM編碼；可參照PKCS#1（RFC8017）查看其具體字段和定義；但密鑰明文存儲方式有所危險，一般可以使用PKCS#8格式（RFC5958）進行密鑰的加密，即設置一個提取密鑰
csr：證書籤發請求，其實與證書內容相似，但不包含簽發方信息，簽發方根據CSR並添加自身的簽發信息，從而生成證書文件，詳情可參照（PKCS#10 RFC2314）
pfx/p12：實際上就是將證書和私鑰一併打包成一個文件，並且設置“提取密碼”
jks/keystore/truststore: 一般常見於JAVA相關應用，實際上也是和p12類似，將證書和私鑰一併打包並設置“提取密碼”，至於keystore和truststore只是概念上的區別，keystore一般用戶表示用戶或服務器證書，而truststore一般表示CA證書。
想要深入研究的童鞋可以看一下PKCS協議族，上述的key、csr、pfx/p12等都是該協議族中定義的相應擴展。後續將會結合本次內容講解以下證書生成。
————————————————
版權聲明：本文爲CSDN博主「DreamerJ」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/jjxojm/article/details/81266601