计算机网络--HTTPS与证书

上一章节说了第一个问题，HTTPS如何数据加密，还剩下两个问题，HTTPS如何做身份验证以及完整性校验

在说者两个问题之前，我觉得有必要先搞清楚几个概念，CA，CA机构，数字证书，数字签名，（证书）指纹，(CA)证书，HTTPS证书，SSL/TLS证书

• CA，CA机构：机构/组织概念。
• 数字证书，(CA)证书，HTTPS证书，SSL/TLS证书：CA签发的数字证书。
• 数字签名，（证书）指纹：CA签发的证书的内容之一，一段加密的密文。

智库百科对数字证书的解释是：

数字证书也称公开密钥证书，是指用于电子信息活动中电子文件行为主体的验证和证明，并可实现电子文件保密性和完整性的电子数据。数字证书是一个经证书认证中心（Certification Authority，简称CA）发行的文件。
数字证书包含有行为主体信息和证书认证机构的数字签名。数字签名是指以电子形式存在，可依附在电子文件中用于辨识电子文件的签署者及表示对该电子文件内容负责所使用的电子数字标识。

抓重点：数字证书用于由CA机构签发的，用于验证主体身份的电子文件，能够实现电子文件的保密性、完整性、反欺诈性。

首先，数字证书=主体信息+数字签名。
Windows下，我们可以在Chrome浏览器上点击地址栏的“锁”标记后会出现下拉框，接着点击“证书”即可看到通过HTTPS访问该服务器时的数字证书。具体操作如下：

• 证书“常规”页面，是关于该证书的一个笼统介绍，包括签发该证书的CA机构、该证书绑定的域名（颁发给）、证书有效期。
• 证书“详细信息”页面，以键值对形式展示了这张证书的完整内容。（后文将详细介绍证书内容）
• 证书的“证书路径”，以层级结构展示了从该证书绑定的域名一直到根证书的路径，这就是证书链。（后文会展开介绍证书链）

总结来看，一张完整的数字证书包括：

• 主体的必要信息：版本(version)、序列号(serialNumber)、签名算法(signatureAlgorithm)、颁发者(issuer)、有效期(validity)、使用者(subject)、公钥信息(subjectPublicKeyInfo)
• 主体的扩展信息(extension)：如密钥标识符、证书策略等
• 数字签名(signature)，也称指纹

抽象为下图：

为什么是数字证书呢？

HTTPS已经对通信数据进行了加密，为什么还要验证身份？说好的“人与人之间最基本的信任呢？”
这还不是因为各路黑客、骇客们总是在制造各种攻击吗？（捂脸）其中一个大名鼎鼎的中间人攻击（Man-In-The-Middle Attack，MITM攻击），简单的讲，“中间人”在客户端和服务端都不知情的情况下，夹在双方之间窃听甚至篡改通信信息，过程见下图（图引自《HTTPS中间人攻击实践（原理·实践）》）：

在HTTPS的握手阶段，一端向对端发送请求，对端返回自己的公钥；如果这时候另一端未验证对方的身份和公钥，直接协商密钥。“中间人”看到了这个漏洞，夹在中间截获了对端的公钥，替换成了自己的公钥。正是这步“拿错了公钥”或者说“信错了对端”，使得HTTPS为加密（密钥协商的非对称加密和通信数据的对称加密）所做的努力全部泡汤。

可见，在HTTPS中，“确保对端身份正确”即“确保拿到的公钥正确”，而在网络通信中所谓的“身份”，一般指的是通信一端的域名、IP地址甚至是Mac地址。所以，数字证书同时包含了通信一端的身份信息和公钥信息。

但是数字证书会在网络中传输（由被要求验证身份的一端通过网络传给另一端），这就意味着证书也可能会被窃取篡改。这个时候权威的CA机构就出马了，他想了个办法：加了一个“防伪标识” — 数字签名。具体做法如下：

signature = RSA(PriKey_CA, Hash(message))

数字签名生成过程是首先对原文作哈希，把一段不定长的文本映射成固定长度的字符空间，接着再用CA机构的私钥对这段定长字符做加密。大大提高了整体的运算效率。

证书是怎么工作的？

要了解证书是怎么做“身份验证”，即“防冒充”，得从2个角度来说明：

• 申请证书，即需要被验证身份的一端，需要申请一份能够验证自己身份的证书
• 验证证书，即需要验证对方身份的一端，拿到证书后验证对端的身份

请注意，这里有一个前提：这张证书必须是由权威CA机构颁发的，且尚在有效期内；或者是一张信任的私人证书。

申请证书
CA机构和证书的分类本文不讨论，推荐阅读《细说 CA 和证书》，这里我们讨论正规权威CA机构签发的证书，至于是DV、OV还是EV，只是安全强度问题，工作原理是一样的。

总结申请证书的过程：用户向CA机构提交自己的信息（如域名）和公钥（用户自己生成的非对称加密公钥，用于TLS握手阶段和另一端协商密钥用），CA机构生成数字证书，如下图：

验证证书

收到对端发过来的证书，执行证书申请的“逆过程”即可，总结如下图：

这个过程中有一个问题：CA机构的公钥怎么获取？
回答：提前内置。

2021.5.4补充更新：下面这个问题困扰了我很久，想通后发现其实原理如此简单。

由于无法知道CA的私钥，所以中间人既然无法修改自己的证书的证书信息，如域名、公司名称等信息，从而达到伪造证书欺骗客户端的目的。但是中间人可以直接下载真正服务端的证书当成自己的证书发给客户端，那不也可以达到欺骗客户端的作用了吗？

其实确实是可以骗得了客户端一时，但是只是一时，并且骗了也没用，因为证书上只有公钥，客户端确实会使用上面的公钥去加密对称加密秘钥给中间人（服务端），但是中间人拿到了这个用公钥加密的对称加密秘钥的密文又能怎样呢？他没有我这个证书上面这个公钥对应的私钥啊，这个私钥只有真正的这个域名对应的服务端才有，所以他一样解不开这个对称加密秘钥的密文，一样无法达到中间人攻击的效果

众所周知，操作系统和浏览器在软件安装阶段会在其特定目录下放置一堆的证书。如Windows的根证书管理在certmgr下：

“受信任的根证书办法机构”下证书都有个特点：权威CA机构发布的根证书（Root Certificate）。根证书有几个特点：

• 没有上层机构再为其本身作数字签名
• 证书上的公钥即为CA机构发布的公钥
• 权威CA机构的自签证书

而这些根证书会跟很多软件，包括操作系统、浏览器一起被安装到用户设备上。即使没有被提前安装好，这些根证书也可以在CA机构的官网上获取得到。
目前全球大型权威CA机构有Symantec、GeoTrust、Comodo以及RapidSSL等，并且这些机构颁发的SSL数字证书，在市场的占有率是非常的高。（节选自《SSL证书颁发机构有哪些》）

本地被内置了这么多的根证书，那要怎么知道我这份证书应该要用哪一个根证书来验证呢？
回答：证书信任链。
在信任链上有3类证书：根证书，中介证书和用户证书。根证书前文已有说明，用户证书就是对端发过来的证书，或者说是用户向权威CA机构绑定了自己身份（主要指域名）和自己公钥的证书。中介证书可以理解由权威CA机构委派的代理机构签发的数字证书，推荐阅读《What is an intermediate certificate?》。中介证书或者说是中介机构的存在是为了保证根证书的密钥的安全性。
细心的同学仔细看一看certmgr会发现有一个分类是“中间证书颁发机构”，这里存放的就是中介证书。用户证书绝大多数是通过权威的CA机构的代理中介机构颁发。

这么来说，根据对端发来的用户证书寻找对应的根证书岂不是更困难了？

自问自答：这是一个在树形数据结构中，从叶子节点搜索根节点的过程，直接一个最原始的深搜（DFS）不就可以了嘛？举例说明，如下图：

1. 从用户证书开始。
2. 记“Issuer”字段的值为i1，搜索本地证书，寻找由“Subject”为i1的证书。
3. 若没有找到，结束返回证书无效；否则，跳到步骤4)。
4. 判断该证书的Issuer值是否等于Subject值。
5. 若是，则该证书是根证书，结束返回该证书；否则跳到步骤6)。
6. 以该证书开始，跳转2)（继续搜索）。

更多关于信任链的知识点，推荐阅读《What is the SSL Certificate Chain?》