一文詳解 HTTPS 與 TLS證書鍊校驗

前一段時間在看

X.509證書結構

與

TLS證書校驗鍊

相關知識，到今天感覺基本了解清楚，想着寫一篇文章記錄學習心得。

在實際工作中，涉及到

X.509證書結構

TLS證書校驗鍊

的場景便是

HTTPS

網絡請求。

這篇文章從

HTTPS

網絡請求開始，詳細介紹

HTTPS秘鑰協商

的詳細流程、

TLS證書

的

校驗

流程、

TLS證書鍊

校驗

流程。

HTTPS

HTTPS簡介。
TLS握手

HTTPS秘鑰協商流程詳細說明。
TLS證書校驗
TLS證書鍊校驗

一、HTTPS簡介

HTTPS

（Secure Hypertext Transfer Protocol）安全超文本傳輸協定，是一種通過計算機網絡進行安全通信的傳輸協定。

HTTPS

利用

SSL/TLS

來加密資料包，經由

HTTP

進行通信。

其設計的主要目的是，提供對網站伺服器的身份認證、保護交換資料的隐私與完整性。

TLS/SSL

TLS 與 SSL某種程度上指的是同一個概念：

SSL （Secure Socket Layer） 1994年由浏覽器開發商 Netscape （美國網景通信公司）率先倡導研發，為資料通訊提供安全支援，開發了最初的幾個版本SSL 1.0、SSL 2.0、SSL 3.0。
TLS （Transport LayerSecurity）前身為SSL，1999年從 3.1 開始被 IETF （Internet Engineering Task Force，Internet 工程任務組）标準化并改名，發展至今已經有 TLS 1.0、TLS 1.1、TLS 1.2 三個版本。

SSL3.0

、

TLS1.0

由于存在安全漏洞，已經很少被使用到。

TLS 1.3

因改動會比較大，目前尚處在草案階段。目前被廣泛使用的是是

TLS 1.1

TLS 1.2

；

如上圖所示，

TLS/SSL

是介于TCP和HTTP之間的一層安全協定。

HTTP

HTTP

（HyperText Transfer Protocol）超文本傳輸協定。

HTTP

是一個用戶端（使用者）和服務端之間請求和應答的标準，其最初的設計目的是為了提供一種釋出和接收HTML頁面的方法。

注：Http協定不是本文重點，感興趣的同學可參考文章：

HTTP 協定詳解：

https://blog.csdn.net/xiaxl/article/details/104541274

二、SSL/TLS 握手

SSL/TLS

握手過程用一句話總結就是：用

非對稱加密

的手段

傳遞密鑰

，然後

用密鑰

進行

對稱加密傳遞

資料。

SSL/TLS

握手，秘鑰協商的過程大緻可分為以下幾個步驟：

1、Client Hello

Client——>Server 用戶端向服務端發送 Client Hello 消息。
2、Server Hello

Server——>Client 服務端向用戶端發送 Server Hello 消息。
3、Certificate

Server——>Client 服務端下發
公鑰證書 。
4、Server Key Exchange

Server——>Client 服務端下發秘鑰交換的額外資料。
5、Server Hello Done

Server——>Client 服務端握手資訊發送完畢。
6、證書合法性校驗

Client 對 Server下發的公鑰證書進行合法性校驗。
7、協商加密秘鑰

Client——>Server 協商計算用戶端、服務端通信的
加密秘鑰enc_key
8、Change Cipher Spec Protocol

Server——>Client 服務端告知用戶端後續的通信都采用協商的
秘鑰enc_key 算法 進行加密通信。
9、Encrypted Handshake Message

Server——>Client 服務端用
秘鑰enc_key 加密，發出的第一條加密消息。
10、Application Data

Client——>Server SSL/TLS 握手完成，所有後續通信均采用
秘鑰enc_key 加密。

SSL/TLS

握手，秘鑰協商的流程圖如下圖所示：

這裡以

用戶端

向

百度首頁

發起

Https

請求為例，用 Wireshark抓包對SSL/TLS握手的各個環節進行介紹，抓包示意圖如下圖所示：

2.1、Client Hello

Client Hello（ Client——>Server ）：用戶端向服務端發送 Client Hello 消息。

消息中包含用戶端的

TSL版本資訊

秘鑰随機數

加密套件候選清單

壓縮算法候選清單

擴充字段等資訊

，相關資訊抓包如下：

各字段較長的描述如下：

Version : 支援的最高TSL協定版本，從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2；
Random：随機數 random_C 用于後續的密鑰協商;
Session ID：有或者無，有則用戶端傳上一次session的id可以恢複session；
Cipher Suite：用戶端支援的密碼算法清單，供伺服器選擇；
Compression Methods：用戶端支援的壓縮算法清單，用于後續的資訊壓縮傳輸；
extensions：擴充字段；

2.2、Server Hello

Server Hello（ Server——>Client ）：服務端向用戶端發送 Server Hello 消息。

消息中包括服務端選擇使用的

TSL協定版本

選擇的加密套件

選擇的壓縮算法

服務端生成的随機數

等，相關資訊抓包如下：

Version：伺服器選擇的版本；
random_S
Cipher Suite：服務端選擇的密鑰算法；
Compression Methods：服務端選擇的壓縮算法；

注：到此用戶端和服務端都擁有了兩個随機數（random_C+ random_S），這兩個随機數會在後續生成對稱秘鑰時會用到。

2.3、Certificate

Certificate（ Server——>Client ）：服務端下發

公鑰證書

給用戶端。相關資訊抓包如下：

Certificate: 服務端的公鑰證書；

注：Certificate 公鑰證書的詳細結構會在下文進行詳細舉例說明。

2.4、Server Key Exchange

Server Key Exchange（ Server——>Client ）: 該消息的目的是攜帶

密鑰交換

額外資料

該消息内容對于不同的協商算法套件會存在差異：

對于使用DHE/ECDHE非對稱密鑰協商算法的SSL握手，伺服器發送其使用的DH參數；
RSA算法不會繼續該握手流程（DH、ECDH也不會發送server key exchange）。

2.5、Server Hello Done

Server Hello Done（ Server——>Client ）:

通知

用戶端

，Server端已經将所有握手消息發送完畢。

2.6、證書校驗

用戶端拿到

服務端

公鑰證書

後，需對該證書的合法性進行校驗。校驗内容如下：

證書鍊的可信性；
證書是否吊銷；
證書有效期；
證書域名校驗，核查證書域名是否與目前的通路域名比對;

注：證書的詳細校驗過程将在下文進行詳細介紹

2.7、協商加密秘鑰

Client——>Server：這一步包含三個步驟，主要是協商計算用戶端、服務端通信的加密秘鑰。

Client Key Exchange

證書合法性驗證通過之後，用戶端産生随機數字
Pre-master 計算生成秘鑰 enc_key
{ enc_key=Fuc(random_C, random_S, Pre-Master) } 。

将
Pre-master enc_key 用 證書公鑰加密 （非對稱加密算法）發送給服務端;
Change Cipher Spec Protocol 用戶端 服務端 後續的通信都采用協商的 密鑰enc_key 和 加密算法 進行加密通信;
Encrypted Handshake Message

用戶端：用戶端将之前
所有的握手資料 （包括接受、發送）生成摘要；然後用 秘鑰enc_key
加密（對稱加密算法），發送給對應的服務端。

服務端：服務端收到消息後，會用
秘鑰enc_key 解密 用戶端的摘要資訊 ；然後用與用戶端相同的算法生成 服務端摘要資訊 ，最後對比兩個摘要資訊相同，則驗證通過。

2.8、Change Cipher Spec Protocol

Change Cipher Spec Protocol（ Server——>Client ）: 伺服器同樣發送 Change Cipher Spec Protocol 以告知用戶端後續的通信都采用協商的

秘鑰enc_key

算法

2.9、Encrypted Handshake Message

Encrypted Handshake Message（ Server——>Client ）：

服務端：服務端會将握手過程的消息生成摘要再用

秘鑰enc_key

加密，這是服務端發出的第一條加密消息;

用戶端：用戶端接收後會用

秘鑰enc_key

解密，能解出來說明協商的秘鑰是一緻的。

2.10、Application Data （ Client——>Server ）

Application Data Client——>Server ）：雙方已安全地協商出了同一份

秘鑰enc_key

，所有的應用層資料都會用這個秘鑰加密後再通過 TCP 進行可靠傳輸。

2.11 總結

SSL/TLS握手協商：用

非對稱加密

傳遞密鑰

用密鑰

對稱加密傳遞

三、證書校驗

這一節對前文

2.6證書校驗

提到的證書校驗流程進行詳細介紹：

1、X.509數字證書結構舉例
2、用戶端如何校驗服務端下發的公鑰證書？

3.1、X.509數字證書

了解證書校驗原理之前，先認識一下X.509證書的結構。

X.509

是密碼學裡

公鑰證書

格式标準

，目前

X.509

證書已應用在包括

TLS/SSL

在内的衆多網絡協定裡。

一個具體的X.509 v3數字證書結構大緻如下 :

// X.509數字證書
Certificate
  // 版本号
  Version Number 
  // 序列号
  Serial Number 
  // 證書簽名算法ID
  Signature Algorithm ID
  // 證書發行者
  Issuer Name
  // 證書有效時間
  Validity period
  // 證書主體名稱
  Subject name
  // 證書主體公鑰資訊
  Subject Public Key Info
    // 證書公鑰算法
    Public Key Algorithm
    // 證書公鑰
    Subject Public Key
  // 發行商唯一ID
  Issuer Unique Identifier (optional)
  // 主體唯一ID
  Subject Unique Identifier (optional)
  // 擴充
  Extensions (optional)

// 證書簽名算法
Certificate Signature Algorithm
// 證書簽名值
Certificate Signature

百度

Tls證書

進行舉例：

Certificate:
	Data:
	    Version: 3 (0x2)
	    Serial Number:
	        72:58:78:36:6e:9f:56:e8:1d:41:88:48
	Signature Algorithm: sha256WithRSAEncryption
	    Issuer: C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
	    Validity
	        Not Before: Apr  2 07:04:58 2020 GMT
	        Not After : Jul 26 05:31:02 2021 GMT
	    Subject: C=CN, ST=beijing, L=beijing, OU=service operation department, O=Beijing Baidu Netcom Science Technology Co., Ltd, CN=baidu.com
	    Subject Public Key Info:
	        Public Key Algorithm: rsaEncryption
	            Public-Key: (2048 bit)
	            Modulus:
	                00:c1:a9:b0:ae:47:1a:d2:57:eb:1d:15:1f:6e:5c:
	                b2:e4:f8:0b:20:db:ea:00:df:29:ff:a4:6b:89:26:
	                4b:9f:23:2f:ec:57:b0:8a:b8:46:40:2a:7e:bc:dc:
	                5a:45:97:4f:ad:41:0e:bc:20:86:4b:0c:5d:55:21:
	                47:e2:31:3c:57:a7:ec:99:47:eb:47:0d:72:d7:c8:
	                16:54:75:ef:d3:45:11:0f:4b:ce:60:7a:46:5c:28:
	                74:ae:8e:1b:be:d8:70:66:7b:a8:93:49:28:d2:a3:
	                76:94:55:de:7c:27:f2:0f:f7:98:0c:ad:86:da:c6:
	                ae:fd:9f:f0:d9:81:32:9a:97:e3:21:ee:04:92:96:
	                e4:78:11:e5:c4:10:0e:10:31:7a:4a:97:a0:eb:c7:
	                9b:c4:da:89:37:a9:c3:37:d7:56:b1:7f:52:c7:d9:
	                26:0a:d6:af:38:16:b1:6d:fb:73:79:b1:68:79:03:
	                90:eb:88:7b:8c:48:91:98:51:a5:07:94:86:a5:78:
	                46:79:8f:58:9b:e9:35:59:a7:f1:7b:57:31:0a:90:
	                cf:24:ce:0d:24:e7:92:b2:6a:e9:e6:96:37:0a:b8:
	                7c:87:2f:74:d2:5c:e8:4b:0a:5f:66:18:a7:41:86:
	                cf:26:a6:08:8e:a5:49:17:92:53:b3:91:a5:cf:53:
	                b0:31
	            Exponent: 65537 (0x10001)
	    X509v3 extensions:
	        X509v3 Key Usage: critical
	            Digital Signature, Key Encipherment
	        Authority Information Access: 
	            CA Issuers - URI:http://secure.globalsign.com/cacert/gsorganizationvalsha2g2r1.crt
	            OCSP - URI:http://ocsp2.globalsign.com/gsorganizationvalsha2g2

	        X509v3 Certificate Policies: 
	            Policy: 1.3.6.1.4.1.4146.1.20
	              CPS: https://www.globalsign.com/repository/
	            Policy: 2.23.140.1.2.2

	        X509v3 Basic Constraints: 
	            CA:FALSE
	        X509v3 CRL Distribution Points: 

	            Full Name:
	              URI:http://crl.globalsign.com/gs/gsorganizationvalsha2g2.crl

	        X509v3 Subject Alternative Name: 
	            DNS:baidu.com, DNS:baifubao.com, DNS:www.baidu.cn, DNS:www.baidu.com.cn, DNS:mct.y.nuomi.com, DNS:apollo.auto, DNS:dwz.cn, DNS:*.baidu.com, DNS:*.baifubao.com, DNS:*.baidustatic.com, DNS:*.bdstatic.com, DNS:*.bdimg.com, DNS:*.hao123.com, DNS:*.nuomi.com, DNS:*.chuanke.com, DNS:*.trustgo.com, DNS:*.bce.baidu.com, DNS:*.eyun.baidu.com, DNS:*.map.baidu.com, DNS:*.mbd.baidu.com, DNS:*.fanyi.baidu.com, DNS:*.baidubce.com, DNS:*.mipcdn.com, DNS:*.news.baidu.com, DNS:*.baidupcs.com, DNS:*.aipage.com, DNS:*.aipage.cn, DNS:*.bcehost.com, DNS:*.safe.baidu.com, DNS:*.im.baidu.com, DNS:*.baiducontent.com, DNS:*.dlnel.com, DNS:*.dlnel.org, DNS:*.dueros.baidu.com, DNS:*.su.baidu.com, DNS:*.91.com, DNS:*.hao123.baidu.com, DNS:*.apollo.auto, DNS:*.xueshu.baidu.com, DNS:*.bj.baidubce.com, DNS:*.gz.baidubce.com, DNS:*.smartapps.cn, DNS:*.bdtjrcv.com, DNS:*.hao222.com, DNS:*.haokan.com, DNS:*.pae.baidu.com, DNS:*.vd.bdstatic.com, DNS:click.hm.baidu.com, DNS:log.hm.baidu.com, DNS:cm.pos.baidu.com, DNS:wn.pos.baidu.com, DNS:update.pan.baidu.com
	        X509v3 Extended Key Usage: 
	            TLS Web Server Authentication, TLS Web Client Authentication
	        X509v3 Authority Key Identifier: 
	            keyid:96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C

	        X509v3 Subject Key Identifier: 
	            ......

3.2、證書校驗

用戶端驗證服務端下發的證書，主要包括以下幾個方面：

1、校驗證書是否是 受信任 CA根證書 頒發機構頒發；
2、校驗證書是否在上級證書的 吊銷清單
3、校驗證書 是否過期
4、校驗證書 域名 是否 一緻

3.2.1、證書可信性

校驗證書是否可信：

校驗證書是否是由受信任的CA根證書頒發機構頒發。

為了確定

用戶端

擷取到的

服務端公鑰

不被篡改，需引入權威的第三方CA機構。

CA機構負責

核實

公鑰

擁有者

資訊、

頒發證書

(對服務端公鑰進行簽名)、同時為使用者

提供證書驗證

服務。

CA機構頒發證書的基本原理：

服務端 生成一對 公鑰 私鑰
服務端 将自己的公鑰提供給 CA機構
CA機構 核實 服務端公鑰
擁有者資訊：

核實申請者提供資訊的真實性：如組織是否存在、企業是否合法、是否擁有域名的所有權等。
CA機構
簽發證書：

CA機構計算伺服器
公鑰摘要資訊 ，然後利用 CA機構私鑰 （CA機構有一對公鑰、私鑰）加密 摘要資訊 加密後的包含 加密摘要 資訊的 服務端公鑰 即 CA機構 頒發的 證書

用戶端驗證服務端公鑰的基本原理為：

用戶端 擷取到服務端的 公鑰
：

Https請求 TLS握手過程中，伺服器公鑰會下發到請求的用戶端。
用戶端 用存儲在本地的 CA機構的公鑰 ，對 服務端公鑰 中對應的 摘要資訊 進行解密，擷取到 服務端公鑰 摘要資訊A
用戶端 根據對 服務端公鑰 進行摘要計算，得到 摘要資訊B
對比 摘要資訊 A與B ，相同則證書驗證通過；

3.2.2、證書吊銷

CA機構

能夠

簽發證書

，同樣也存在機制

宣布

以往簽發的

證書無效

。若證書的申請主體出現：

私鑰丢失

申請證書無效

等情況，CA機構需要廢棄該證書。

主要存在兩類機制：CRL 與 OCSP。

CRL（Certificate Revocation List）

證書吊銷清單：是一個單獨的檔案，該檔案包含了 CA機構已經吊銷的證書序列号與吊銷日期；

證書中一般會包含一個 URL 位址
CRL Distribution Point
，通知使用者去哪裡下載下傳對應的 CRL 以校驗證書是否吊銷。

該吊銷方式的優點是不需要頻繁更新，但是不能及時吊銷證書，因為 CRL 更新時間一般是幾天，這期間可能已經造成了極大損失。
OCSP（Online Certificate Status Protocol）

證書狀态線上查詢協定：一個實時查詢證書是否吊銷的方式。

請求者發送證書的資訊并請求查詢，伺服器傳回正常、吊銷或未知中的任何一個狀态。

證書中一般也會包含一個 OCSP 的 URL 位址，要求查詢伺服器具有良好的性能。

部分 CA 或大部分的自簽 CA (根證書)都是未提供 CRL 或 OCSP 位址的，對于吊銷證書會是一件非常麻煩的事情。

3.2.3、證書過期

校驗證書的有效期是否已經過期：主要判斷證書中

Validity period

字段是否過期。

3.2.4、證書域名

校驗證書域名是否一緻：

核查

證書域名

是否與目前的

通路域名

比對

舉例中：

我們請求的域名 www.baidu.com 是否與

證書檔案

中

DNS标簽

下所列的

域名

相

比對

一種錯誤的寫法：

Android 軟體開發中，我們經常會遇到以下代碼，用來忽略證書的域名驗證，其實這是一種不安全的寫法：

// 對于自簽名證書，用以下代碼來忽略證書的域名驗證
HostnameVerifier hostnameVerifier = new HostnameVerifier() {
    @Override
    public boolean verify(String urlHostName, SSLSession session) {
		// 忽略證書的域名驗證
        return true;
    }
};

四、證書鍊校驗

上一節介紹證書校驗場景，适用于

伺服器證書

的簽發機構就是

Ca機構

實際證書申請中，由于權威的

CA機構

數量不多，若所有的

伺服器證書

都向權威CA機構申請，那麼CA機構的工作量就會非常大。是以CA機構采取

授權

二級機構

的方式來管理證書申請，經

授權

二級機構

也可以簽發

伺服器證書

4.1、證書鍊校驗

證書簽發：

根證書 CA機構使用自己的 私鑰 對 中間證書 進行簽名，授權 中間機構 證書；
中間機構 使用自己的 私鑰 伺服器證書 進行簽名，進而授權 伺服器證書

證書校驗：

用戶端 通過 伺服器證書 簽發機構資訊 ，擷取到 中間證書公鑰 ；利用 中間證書公鑰 伺服器證書
的簽名驗證。

a、中間證書公鑰解密伺服器簽名，得到證書摘要資訊；

b、摘要算法計算伺服器證書摘要資訊；

c、然後對比兩個摘要資訊。
用戶端 中間證書 簽發機構資訊 ，用戶端本地查找到 根證書公鑰 根證書公鑰 中間證書

4.2、中間證書怎麼擷取？

這裡可能大家有一個疑問，根證書是内置在終端裝置上或浏覽器中的，那中間機構證書怎麼擷取？

這裡仍以

百度

Tls證書

進行舉例，百度

伺服器證書

簽發者公鑰

（中間機構公鑰）通過下圖中的URI擷取：

五、參考

TSL标準：

https://tools.ietf.org/html/rfc5246

X.509标準：

https://datatracker.ietf.org/doc/html/rfc5280

SSL/TSL 原理：

https://www.cnblogs.com/chenjingquan/p/10531305.html

TLS/SSL握手過程：

https://blog.csdn.net/hherima/article/details/52469674