前言
如何证明「我爸是我爸」这种问题非常扯,但是在互联网中,我们需要一个基本的信任关系,来证明「你是你」。
就像我们在访问 HTTPS 网站的时候,如何证明对方服务器就是我们想要访问的目标呢?答案就是靠权威机构和信任链机制
信任链和证书认证
类比一下我们生活中的信任关系,我们都有自己信任的朋友,假设我信任 A,然后 A 信任 B,那么我们通常能够将这个信任链条延伸,也就是我可以相信 B。
证书的信任链也是基于这样一种基础的信任链模型实现的。
关键点
信任链 & 传递信任机制。
比如:我信任 Bob,Bob 信任 Alice,那么我就能信任 Alice。只要这条信任链中没有人受影响,那么我们就能不断扩大这条信任链。
Web 中的应用
浏览器是如何决定应该信任谁的呢?
至少有三种方式:
- 手动指定证书 每个浏览器和操作系统都提供一个机制,让你手动导入任何你信任的证书。你如何获得证书并验证其完整性,完全取决于你。
- 证书颁发机构 证书颁发机构(CA)是一个受信任的第三方,它受到证书主体(所有者)和依赖该证书的一方的信任。
- 浏览器和操作系统 每个操作系统和大多数浏览器都有一个知名的证书颁发机构的列表。因此,你也相信这个软件的供应商会提供并维护一个受信任方的名单。
在实践中,为每个网站存储和手动验证每一个密钥是不切实际的(尽管你可以,如果你有这样的倾向)。因此,最常见的解决方案是使用证书颁发机构(CA)来为我们做这项工作:浏览器指定信任哪些 CA(根 CA),然后由 CA 来验证他们签署的每个网站,并审计和验证这些证书没有被滥用或破坏。如果任何持有该 CA 证书的网站的安全性被破坏,那么该 CA 也有责任撤销被破坏的证书。
每个浏览器都允许你检查安全连接的信任链,通常可以通过点击URL旁边的锁图标进行访问。

如上图所示,
- igvita.com证书是由StartCom Class 1 Primary Intermediate Server签署的。
- StartCom Class 1 Primary Intermediate Server证书是由StartCom认证机构签署的。
- StartCom认证机构是一个公认的根证书机构。
整个链条的 "信任锚 "是根证书颁发机构,在刚才的例子中,它是StartCom认证机构。每个浏览器都有一个预先初始化的受信任的证书颁发机构("根")列表,在这种情况下,浏览器信任并能够验证StartCom根证书。因此,通过对浏览器、浏览器供应商和StartCom证书颁发机构的横向信任链,我们将信任扩展到我们的目标网站。如下图所示:
flowchart TD
id1(root CA) --信任--> id2(中间 CA 服务器) --信任--> id3(目标网站)术语 & 概念
了解了证书的这套信任机制后,我们还需要再深入以下概念。
信息摘要
一段信息,经过摘要算法得到一串哈希值,就是摘要(digest)。
常见的摘要算法有MD5、SHA1、SHA256、SHA512等。
主要是用于「校验信息的完整性」。
数字签名
摘要经过私钥的加密后,便有了一个新的名字 -- 「数字签名」。
问:有了信息摘要,为何还要有数字签名?
答:信息摘要,虽然也不可逆,但却容易却被伪造。所以信息摘要只用于校验完整性,而要保证信息摘要的正确性,就要依靠数字签名啦。
问:为什么不对内容直接加密,而是对摘要进行加密。
答:由上面我们知道了非对称加密的速度非常慢,如果传输的数据量非常大,那这个加密再解密的时间要远比网络传输的时间来得长,这样反而会得不偿失。
如果我们对传输的内容只有完整性要求,而安全性没有要求(意思是传输的内容被人知道了也没关系)。那就可以对摘要进行加密,到客户端这里解密后得到摘要明文,再用这个摘要明文与传输的数据二次计算的摘要进行比较,若一致,则说明传输的内容是完整的,没有被篡改。
数字证书
flowchart LR
idcert([数字证书])
id1(服务器公钥) --哈希算法--> id2(信息摘要)
id2 --用 CA 的私钥加密--> id3(数字签名)- 数字证书是什么东西?
其实它就是一个
.crt 文件- 数字证书是谁颁发的?
由权威证书认证机构颁发,一般我们简称为 CA 机构
- 数字证书如何申请的?或者说如何颁发的?
- OpenSSL 生成密钥对
- 使用「公钥+申请者信息+域名」生成证书签名请求文件
.csr,发送到 CA 机构 - CA 机构使用哈希算法对这个证书生成摘要
- CA 机构使用 CA 的私钥对证书摘要进行加密,得到签名,附带到证书上,证书文件以
.crt结尾 - CA 机构再将
.crt证书返还给申请者
见下图 👇:

.png?table=block&id=257034f2-32b0-4af8-943e-856b7709528e&cache=v2)