前一段时间在看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：随机数 random_S 用于后续的密钥协商;
• Session ID：有或者无，有则客户端传上一次session的id可以恢复session；
• 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

= THE END =