證書組成
在介紹證書內容之前,我們先看看怎么向 CA 申請一個證書,這有助于你了解整個系統的運作過程。
證書申請
首先我們要生成一個 CSR,它的全稱是 Certificate Signing Request,這個文件包含了你要申請的證書的各種信息,這和在某個 CA 的后臺填寫一個申請表單是一個意思,只是這樣可以規范所有 CA 遵守一致的規則。
這里我們需要使用一個叫 openssl 的軟件,執行下面的命令:
openssl req -new -newkey rsa:2048 -nodes -keyout www.javadoop.com.key -out www.javadoop.com.csr
進入交互界面后,需要你填寫國家、城市、公司名字、部門名字、申請的域名、郵箱地址。有些 CA 支持中文,大部分不支持,這里建議都是用英文字符。
然后我們就會得到兩個文本文件:
www.javadoop.com.csr
www.javadoop.com.key
其中一個是 CSR 文件,用來發給 CA 申請證書的,另一個是私鑰。私鑰需要好好保存,等證書申請完成以后要用。
從域名的角度,證書分為單域名、通配符域名、多域名證書。這里我以單域名 www.javadoop.com
為例子,通配符和多域名也很好理解,在填寫域名的時候按照格式填就可以了。
我們來看一下生成出來的 www.javadoop.com.csr
文件,它的內容是這樣的:
-----BEGIN CERTIFICATE REQUEST-----
MIIC2DCCAcACAQAwgZIxCzAJBgNVBAYTAkNOMREwDwYDVQQIDAhTaGFuZ0hhaTER
MA8GA1UEBwwIU2hhbmdIYWkxFTATBgNVBAoMDEphdmFkb29wIEluYzELMAkGA1UE
CwwCSVQxFzAVBgNVBAMMDiouamF2YWRvb3AuY29tMSAwHgYJKoZIhvcNAQkBFhF0
ZXN0QGphdmFkb29wLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMucZll8pn6z+IObP0re4mhC7VySQjC84qBRsr6rOCbcoRjDfAgAmxQbFabMgZ4E
l1uEU+MhIZU0UfW5jZv+A3HW3fxGt++9f/kH3jj0tGpinMoR+HJXjAYtCaYzLCTy
u/dEhXZv2TqUegRW1J5/2naAzq5VtaL2lN1fTOKpXxeYnduTma7kzZYAaOT5XO5x
jxnIhm9ogaRdGPrdsj88WcaHXjaAE+ERwK0l0/o9nDm5DnY3IGAQNz0Ft0TdQxjj
GZtBFjl46FPg8KS9YgiUInw///c6k459XvMTHGmSO1eXe/7yA/uUt4SLNIGsfO8K
5GV7P0qxc2beDiHWht3lDDcCAwEAAaAAMA0GCSqGSIb3DQEBCwUAA4IBAQAANyqP
H84rTYt5MRe/vKR4+/ZDVZa867vCt9zlGrm/3Qz/sXyFpTlTzhMCvuE0ZS1vzKTJ
9jzTimaIVF1pKWhgNsCfw4MuUjxXT6PRuHmCYWZLST6JxaXZdfzZXe+v5UlJW2UI
4/l9A1z7wc+tFlxc+GhQcvB5iaFLvmh6VMabMsHEZUWw5RA5enVhDHMvrlyRB2GG
oN1nvzptFxms5T6qVjEj4VXiQLgPPIx54owiBtyP55uKYH6Nf3JkfQjfFFKcTkZI
yhpVsgr300wAZfdWZI1z99442omCEALvFy/4DQixcnKkowOrHpVoAcyI7VlBfl/8
4cID+7D+EnlMU6xF
-----END CERTIFICATE REQUEST-----
我們找個網站在線 decode 一下這個內容,比如我們用這個網站 https://decoder.link/result 進行 decode,可以得到下面的內容:
Certificate Request:
Data:
Version: 1 (0x0)
Subject: C = CN, ST = ShangHai, L = ShangHai, O = Javadoop Inc, OU = IT, CN = www.javadoop.com, emailAddress = test@javadoop.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c8:3f:ad:7c:df:a6:ad:6f:1e:82:14:de:cd:d9:
d1:64:1b:06:a1:9c:79:85:cb:66:34:af:87:c0:78:
86:10:64:04:a0:53:11:62:b4:47:49:ab:cc:93:e1:
b9:c9:46:cc:0c:ce:fa:a5:7c:54:97:4f:98:92:ed:
57:c2:23:08:48:fa:87:7c:d8:fe:08:6e:97:fd:65:
e8:3f:87:fa:19:38:20:6f:b3:35:04:7e:5b:2c:65:
3d:de:9d:57:c9:14:06:34:54:f3:72:90:77:f7:8d:
eb:2b:12:c5:31:ed:ce:44:0c:a3:3c:5f:63:72:16:
8f:1e:38:74:6e:80:19:fa:b1:83:76:62:b2:d3:dc:
0d:ec:69:32:1d:93:e1:6f:6d:a3:ba:74:62:7c:21:
a3:2a:c6:11:3d:6a:90:e4:28:c8:d5:95:a3:e1:92:
70:3c:3c:5f:13:54:f5:ac:6b:d1:e8:cd:75:6a:82:
3c:8d:81:35:1e:da:23:b7:9d:e7:c4:78:a9:54:89:
b5:89:5b:88:5a:f2:a2:42:b8:a8:b6:80:b9:dc:4e:
24:09:65:8f:81:d9:9b:f5:7d:86:41:bf:6e:8d:4e:
61:a4:b2:d5:cb:fa:cc:ce:27:f1:5f:03:36:3c:ad:
cd:f2:ea:65:5e:42:b8:8f:c8:0d:c2:53:16:39:4c:
c8:d5
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
8d:71:ac:d2:62:33:6c:c8:db:64:6f:a9:d1:11:38:c9:f5:02:
e3:bd:cc:c1:92:6b:19:69:3f:2d:07:42:fe:e3:96:c7:dc:52:
bd:f9:3b:1d:2f:7b:74:a1:f5:b7:a6:bc:e1:d6:cd:ad:6a:38:
c1:6d:5e:d7:ce:1b:84:47:fd:8d:e9:9b:cb:0d:8e:d9:e1:8c:
7b:24:d4:be:cf:b8:78:e3:77:1c:7c:81:8a:ad:b7:db:0d:a6:
70:b4:7d:8d:8b:55:03:8f:f2:08:28:0a:0f:3e:f8:a4:b7:1a:
f0:17:04:e3:08:15:35:c6:be:fc:eb:c8:29:c0:b3:73:52:65:
42:93:f3:fd:d6:23:70:b2:4b:3d:3f:4a:9f:bb:32:9d:5c:74:
d6:3d:de:3d:c5:f9:b1:6b:47:6f:fb:34:92:40:50:ca:47:4a:
71:30:5d:6d:a6:69:67:1d:df:c9:bd:06:9b:7c:c7:77:0c:24:
03:9d:5f:17:a8:de:c8:12:1a:b3:aa:b1:ba:f4:22:c1:e1:c4:
2a:47:2f:10:45:ca:fd:60:b7:21:4c:00:af:1c:a0:d0:fb:dc:
39:ee:c6:0d:06:da:e3:e6:d9:d1:f3:21:39:bb:dc:e4:a8:56:
f7:41:9f:76:72:00:83:ca:c0:9e:05:a0:2a:93:02:5e:90:44:
09:aa:15:3e
第一部分:Subject 中是我們填寫的域名的基本信息,這里面,我們只需要關注 CN 字段就行:www.javadoop.com
。CN 是 Common Name 的縮寫。
第二部分:Subject Public Key Info 是公鑰部分,這里指定了服務器使用的加密算法是 RSA,公鑰長度是 2048 位。
第三部分:簽名,使用了 sha256WithRSAEncryption 算法。也就是說首先將上面的所有信息進行 sha256 散列得到 hash 值,然后使用 RSA 算法對 hash 值進行加密,而加密的秘鑰就是之前生成的私鑰。
為什么這里要加第三部分的簽名?其實就是為了防止你的 CSR 文件在發給 CA 的過程中被中間人攔截,然后修改了里面的信息再發給 CA。
CA 的校驗過程是:利用里面的公鑰將簽名進行解密得到里面的散列值,然后 CA 也會利用 CSR 里面的信息計算一遍散列值,如果兩者相等,那么說明證書沒有被中間人修改過,反之就是被修改過。
關鍵詞:CSR 文件,包含了證書申請的信息,加密和散列算法,以及公鑰。同時我們現在有了私鑰。
證書組成
CA 收到我們的 CSR 文件以后,CA 會進行審核,前面說過了,審核這個域名是不是你的,如果需要,還有人工審核公司信息。審核通過后,它就會發給我們證書文件了,每家 CA 出來的文件名可能略有不同,但是表達的信息是一樣的。
主要有以下幾個文件:
-
域名證書:
www.javadoop.com.pem
或叫cert.pem
-
證書鏈:
fullchain.pem
這些文件可能是 .pem
也可能是 .crt
后綴,但都是文本文件,可以直接打開查看它們的信息:
域名證書的文件內容通常是這樣的:
-----BEGIN CERTIFICATE-----
MIIFTzCCBDegAwIBAgISAy4b8ie6L/ACCJt/V7x/OR0iMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
......
Ecbqh4AoB33mZhp9ptJb1N1RSlZREI0FlbX0kUd6VowKUPhH8Iex6jxQpJHwRkpq
YJaWKrUxGWuJurOcN7b3HXn6yw==
-----END CERTIFICATE-----
證書鏈文件通常是這樣的:
-----BEGIN CERTIFICATE-----
MIIFTzCCBDegAwIBAgISAy4b8ie6L/ACCJt/V7x/OR0iMA0GCSqGSIb3DQEBCwUA
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD
.......
Ecbqh4AoB33mZhp9ptJb1N1RSlZREI0FlbX0kUd6VowKUPhH8Iex6jxQpJHwRkpq
YJaWKrUxGWuJurOcN7b3HXn6yw==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEkjCCA3qgAwIBAgIQCgFBQgAAAVOFc2oLheynCDANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
.......
PfZ+G6Z6h7mjem0Y+iWlkYcV4PIWL1iwBi8saCbGS5jN2p8M+X+Q7UNKEkROb3N6
KOqkqm57TH2H3eDJAkSnh6/DNFu0Qg==
-----END CERTIFICATE-----
這里貼了部分內容,是想要告訴大家:證書鏈文件的第一部分,和證書文件的內容是一模一樣的。
如果 CA 還給你發了
chain.pem
文件,其實它的內容肯定就是證書鏈文件內容裁減掉第一部分的證書內容而已。
很多 CA 還會根據你的證書配置環境是 Nginx、IIS、Tomcat 等,給我們分為好幾個不同的文件,但是說到底我們需要的其實就是一個證書鏈。
我上面貼的證書鏈就兩部分內容,但是大家要知道,這個鏈是可以更長的。
關鍵詞:CA 給我們頒發的證書,其實就是一個證書鏈文件
證書內容
接下來,我們來說說證書里面的內容到底是什么?
其實證書鏈上的每一個節點的內容都是類似的,我以 javadoop.com 的證書為例,將其進行 decode 后的結果如下:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:76:e6:d1:15:1e:bb:72:04:ae:f9:f5:d6:ad:0b:f9:ab:81
Signature Algorithm: sha256WithRSAEncryption
// 證書頒發機構
Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
// 證書的有效期
Validity
Not Before: Apr 20 07:30:33 2020 GMT
Not After : Jul 19 07:30:33 2020 GMT
// 證書申請信息
Subject: CN = javadoop.com
// 公鑰
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d2:34:73:fb:83:e3:f0:82:f0:c8:ce:ab:50:e7:
d4:a4:14:e9:e2:a3:f1:61:bb:7e:db:b1:c9:e7:01:
49:c4:9c:89:e8:f0:25:bf:0d:1d:e0:e3:8d:df:7e:
16:ea:ab:0c:a9:5a:04:fb:ef:e5:09:4d:6e:21:5c:
d8:e8:39:38:46:69:91:49:04:6a:e1:83:6c:8e:5f:
16:7b:a4:d5:45:6e:16:a2:81:12:65:7e:a5:dc:60:
05:73:23:91:59:b3:1c:13:0b:25:15:2b:c0:27:80:
e6:ce:f8:d9:85:c0:0e:96:74:36:1a:78:fd:4c:2f:
82:66:16:00:ea:42:65:c3:25:ea:df:0d:5e:67:97:
65:85:0f:17:87:41:8a:3d:df:d2:93:b7:04:2d:15:
49:11:67:77:5b:49:29:6d:13:4b:c5:4f:9b:aa:e4:
1d:69:2b:8b:b3:c2:08:47:bf:f7:19:28:af:54:8b:
f3:6d:33:ad:4b:21:5e:42:07:08:15:03:06:b8:e5:
bc:93:fc:14:2f:d0:6d:e7:a0:34:86:8e:63:16:f3:
7f:e0:09:cd:1a:6b:ab:87:2d:b9:26:5f:17:5f:72:
10:05:5f:d1:d8:96:ab:0b:db:b5:25:15:99:49:8a:
0c:99:a7:e7:02:22:aa:92:29:50:7d:d3:44:25:7a:
18:97
Exponent: 65537 (0x10001)
// 這部分內容我們忽略
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
36:89:CF:2A:C8:0B:34:8F:9D:0D:F8:D8:DD:DF:4F:B6:89:19:77:DF
X509v3 Authority Key Identifier:
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Alternative Name:
DNS:javadoop.com, DNS:www.javadoop.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : E7:12:F2:B0:37:7E:1A:62:FB:8E:C9:0C:61:84:F1:EA:
7B:37:CB:56:1D:11:26:5B:F3:E0:F3:4B:F2:41:54:6E
Timestamp : Apr 20 08:30:33.880 2020 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:90:A7:C6:DD:84:2C:F8:90:38:BC:C7:
BB:4E:A7:46:38:68:5D:F2:9D:40:57:9E:12:9D:F6:85:
42:B5:E2:6A:9A:02:21:00:DE:B7:EA:51:98:34:D0:70:
CF:4E:94:F4:B0:32:13:70:68:2A:D7:8C:38:9D:13:FD:
EF:5F:B1:09:B8:1E:36:D9
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 07:B7:5C:1B:E5:7D:68:FF:F1:B0:C6:1D:23:15:C7:BA:
E6:57:7C:57:94:B7:6A:EE:BC:61:3A:1A:69:D3:A2:1C
Timestamp : Apr 20 08:30:33.929 2020 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:46:02:21:00:DC:21:FE:44:A5:EB:03:27:D4:3A:25:
62:D1:2D:9B:F8:8C:D6:B8:27:3D:CE:17:C9:25:8A:71:
E0:4A:7F:7B:08:02:21:00:9F:13:05:62:9C:79:F4:33:
19:4B:B9:BA:86:64:87:28:20:B7:C3:28:06:26:B7:52:
95:2C:EF:69:13:A5:14:D1
// 簽名
Signature Algorithm: sha256WithRSAEncryption
7f:3a:c5:1d:88:67:6d:40:c1:34:ac:01:9c:44:32:b1:8a:6d:
1d:c6:bc:e7:52:5c:e4:42:0b:14:17:bd:47:4b:36:52:5c:eb:
94:11:99:9b:82:b6:2b:db:43:b1:85:a2:38:54:32:e7:9c:8f:
53:b2:6f:c8:7f:ef:bb:17:c5:c1:08:ec:65:33:0b:8c:dc:e2:
20:c0:29:99:20:cc:a4:9a:80:9e:f6:ef:04:34:bc:0d:f2:53:
ce:98:2e:a6:a8:33:c0:24:0e:ca:d4:f9:fc:99:cc:d3:df:96:
12:f5:69:b3:f1:72:33:26:81:87:16:71:0e:35:a2:91:29:44:
ce:33:fb:95:81:de:5b:a3:8c:07:ff:b6:f7:90:c0:3f:62:f2:
3e:e4:45:cc:41:43:f6:27:2f:f0:b3:bb:8e:3d:ce:37:05:e5:
30:be:c9:a4:32:7a:6c:a8:57:eb:ce:66:46:9b:fd:b5:13:1b:
61:bf:05:7e:6f:9e:e0:99:77:8f:5a:eb:a5:79:3e:3a:57:dc:
38:2b:3d:3e:39:31:f1:46:f2:b6:b1:4f:80:06:6e:4f:3b:ff:
94:fb:74:b7:6d:01:ea:ae:5f:a7:3f:d3:24:eb:ea:7e:c4:ef:
7c:97:4f:be:eb:f9:87:fd:64:b9:e7:0f:3c:b1:c1:51:4a:fe:
86:eb:8d:95
證書中主要包含:
- 證書頒發機構:用于尋找鏈中的下一個驗證節點
- 證書的有效期:比如瀏覽器要根據這個值來判斷證書是否已過期
- 證書申請信息:比如瀏覽器要判斷改證書是否可用于當前訪問的域名
- 公鑰:用于后續和服務端通信的秘鑰,這個公鑰和當初生成 CSR 時的公鑰是一個東西,因為只有它是和服務器的私鑰是一對的
- 簽名:用于驗證證書內容沒有被篡改
這里簡單說一說這個證書里面的公鑰和簽名:
前面在介紹生成 CSR 的時候,我們說過了,簽名部分,是服務器使用私鑰加密 hash 值得到的,同時在 CSR 中包含了公鑰,這樣 CA 在收到這個文件后,可以用 CSR 文件中的公鑰來解密簽名,進而做校驗。
而這里不一樣,這個證書是 CA 給我們的,自然這個簽名也是 CA 使用它自己的私鑰進行加密的,但是這里的公鑰是我們服務器的公鑰,顯然不能用于解密簽名。
那對于用戶瀏覽器來說,在收到這個證書以后,怎么校驗這個證書的簽名呢?顯然瀏覽器需要得到 CA 的公鑰。下一節我們就將詳細描述這個過程。
HTTPS 驗證過程
其實,前面已經把大部分內容都說完了,我們只需要知道最后一步,怎么得到 CA 的公鑰就可以了。
我們以一個實際的例子來分析,下面將使用 javadoop.com 這個域名的證書來分析。
首先,我們可以看到,這個證書鏈由 3 個證書組成。javadoop.com
證書由中間證書 Let's Encrypt Authority X3
簽發,中間證書由 DST Root CA X3
簽發,而 DST Root CA X3
是一個受信任的根證書。
流程如下:
1、用戶訪問 https://javadoop.com
,服務器返回 CA 給的證書鏈,其中包含了 javadoop.com
證書以及中間證書;
2、瀏覽器首先需要判斷 javadoop.com 的證書是不是可信的,關鍵的一步就是要解密證書的簽名部分。因為證書是由中間證書簽發的,所以要用中間證書里面的公鑰來進行解密;
3、第 2 步初步判斷了 javadoop.com 的證書是合法的,但是,這個是基于中間證書合法的基礎上來的,所以接下來要判斷中間證書是否是合法的;
4、根據中間證書里面的信息,可以知道它是由 DST Root CA X3
簽發的,由于證書鏈只有兩個節點,所以要到操作系統的根證書庫中查找,由于這個證書是一個使用非常廣泛的根證書,所以在系統中可以找到它。然后利用根證書的公鑰來解密中間證書的簽名部分,進而判斷中間證書是否合法,如果合法,整個流程就通了;
我們思考一下:
- 這個系統要工作好,關鍵就是最終一定要走到本地根證書庫,一環驗證一環,實現整個鏈路證書的可信任;
- 中間證書有多少層都可以,只要能一直傳遞到根證書就行;
- 本地的根證書是由操作系統內置的,如果你的使用場景中,根證書不在系統預裝里面,需要手動導入根證書;
另外,我這里使用了操作系統內置這個說法,其實也不準確吧,各大瀏覽器廠商可以自己內置這個根證書庫,這樣我想信任誰就信任誰,而不是聽 Microsoft、Apple... 這些操作系統廠商的。
腦洞大開一下,如果你想開一家 CA 公司,技術上是沒什么成本的,但是你要說服各大操作系統、瀏覽器廠商,把你家的根證書內置到里面,這就有點難了。當然,還有另一條路可以走,那就是不要搞根證書,基于某個 CA 搞個中間證書,然后用這個中間證書去簽發證書就可以了。