【网络协议】数字签名与证书

一、什么是数字签名（Digital Signature）

定义：利用 非对称加密（公钥/私钥对）来实现 数据的完整性保证 和 身份真实性证明 的一种技术。

用私钥签名、公钥验证

过程：

1. 发送者用 私钥 对消息的摘要（hash）进行加密，得到 数字签名。
2. 接收者收到消息和签名后，用发送者的 公钥 去解密签名，再与消息重新做哈希对比。如果匹配，证明消息没被篡改，且确实来自持有私钥的人。

作用：

• 防篡改：即完整性证明。
• 防伪造：因为只有私钥持有人能生成签名。
• 不可否认性：发送者不能否认自己曾发出这条签过名的数据。

其中：

加签（数字签名）= 用 密钥 + 算法 对数据生成一个“唯一的指纹”。

• 就像在纸质合同上盖章或签名，证明“这份合同是我出的，而且没被改过”。
• 在网络传输里，用哈希函数（SHA256 等）+ 密钥（对称密钥或私钥）生成一个字符串，这个字符串就被称作“签名”。

二、什么是数字证书（Digital Certificate）

**定义：**数字证书是 一种网络安全凭证，用来证明某个实体（比如个人、组织、网站）的身份，并保证通信过程中信息的安全性。它就像网络世界里的“电子身份证”。

1. 数字证书（典型的 X.509 证书）主要包含

1. 证书持有者信息（Subject）
   • 申请者的身份：域名（CN, SAN）、组织、部门、国家等。
2. 证书持有者的公钥（Subject Public Key Info）
   • 网站/组织/个人生成的公钥。
3. 证书签发者信息（Issuer）
   • CA 的身份：名称、组织、地址等。
4. 有效性信息
   • 有效期起止时间、序列号、证书用途（如服务器认证、客户端认证、代码签名）等。
5. 签名算法（Signature Algorithm）
   • 例如 SHA256-RSA、ECDSA-SHA384。
6. 签发者签名（Signature Value）
   • CA 使用 自己的私钥 对前面内容（证书主体信息）做数字签名，保证内容未被篡改。
7. 序列号：唯一标识该证书。

作用

身份认证：确认通信对方的真实身份（如访问一个HTTPS 网站时，浏览器会检查网站证书），防止中间人攻击。

举个例子：
当你访问一个银行网站时，浏览器会验证该网站的数字证书。只有当证书有效且由可信CA签发时，浏览器才会显示安全连接的小锁🔒标志，这样你才能确认自己访问的是正规的银行网站，而非钓鱼网站。

2. 证书和密钥的关系

我们说的 公钥/私钥对（key pair） 是一对数学相关的密钥：

• 私钥：用来签名或解密，必须保密
• 公钥：用来验证签名或加密，可以公开

使用时：

• 先生成密钥对
• 把公钥交给 CA，CA 验证后会为它生成/签名一个证书
• 设备最终拥有：
  1. 私钥文件（本地保管，不会放进证书）
  2. 证书文件（包含公钥和身份信息，外界可拿证书里的公钥来验证你）

3. 证书的后缀

. .PEM、.CRT 后缀的证书有什么区别？

• 本质上：PEM 与 CRT 没有“内容上的冲突”，都可以存放 X.509 证书。

• 差别在于：

  • .pem → 强调文件存储格式：Base64 编码 + 文本头尾。
  • .crt / .cer → 强调文件功能：这是“证书文件”。

• 在实际使用中，扩展名只是习惯，而不是强制标准。你完全可能遇到 .crt 文件里内容其实是 PEM 格式的。

• ESP32 常用 .pem 文件 → 强调文件存储格式，因为框架喜欢“纯文本”证书，容易加载/硬编码。

• 浏览器常用 .crt 文件 → 强调文件功能，因为这是 OS/浏览器生态里管理证书的通用习惯。

三、证书认证（Certificate Authentication）

证书认证（Certificate Authentication） 是一种基于数字证书的身份验证方式，它利用 公钥基础设施（PKI） 来确保证书持有者（个人、设备、服务器或应用）的真实身份。

就像现实中用身份证来证明“我是我”，在网络通信中用数字证书来证明“这是我的服务器”或“我是合法的用户”。

1. 证书认证的原理

1. 证书颁发：用户或服务器先向权威认证机构（CA）申请数字证书。CA 会验证其身份后通过 私钥签名签发证书。

2. 证书验证流程：

   1. 客户端获取证书。
   2. 从证书中提取 TBSCertificate（主体部分），计算 Hash2。
   3. 使用证书里声明的签名算法和 颁发者的公钥，对签名字段做验证，得到 Hash1。
   4. 比较 Hash1 == Hash2 → 如果一致，说明证书内容没有被篡改，确实由颁发者签发。
   5. 同时检查证书时间有效性、吊销状态，并沿着信任链逐级验证直至根证书。
   6. 如果所有检查均通过，证书才被认为“可信”。

   在这里提到颁发者的公钥：在一个证书（例如网站证书）里，包含的是 持有者的公钥（Subject Public Key Info），而没有颁发者的公钥。颁发者的公钥并不会直接出现在下级证书里，而是存在于 颁发者自己的证书（Issuer Certificate）中。

   那么验证链是如何工作的：

   1. 浏览器收到服务器证书
      • 用其中 Issuer=Intermediate CA 的信息 → 发现需要中间 CA 的公钥。
   2. 服务器同时发来中间 CA 证书
      • 中间 CA 证书的 Public Key 就是验证服务器签名所需的“颁发者公钥”。
   3. 再验证中间 CA 证书
      • 它由根 CA 签发 → 需要根 CA 公钥。
   4. 根 CA 的公钥 来自浏览器/操作系统的信任根库
      • 验证成功以后，就说明整个链条可信。

   因此证书的验证，是一个完整的信任链验证过程

   • 沿着签发关系找到上级 CA → 一直验证到 根 CA。

   • 根 CA 必须在客户端的 操作系统/浏览器信任库中才算最终可信任。

   证书验证不仅仅是“签名对得上”，还要过有效期、吊销、以及完整的信任链检查，最后才能被客户端认为是可信证书。

   常见的，当你访问一个 HTTPS 网站时：

   • 服务器会将自己的服务器证书发给浏览器。
   • 浏览器会使用 CA 的公钥来验证该证书是否真实有效、是否未过期或未被吊销。
   • 验证通过后，再使用证书中的公钥加密数据。
   • 建立信任：通过确认证书有效性，通信双方可以安全地交换数据。

应用场景

• HTTPS 网站登录：浏览器通过网站证书确认访问的是真正的网站。

• VPN 访问：企业员工远程登录时，通过个人数字证书验证身份。

• 客户端/服务器双向认证（Mutual TLS, mTLS）：不仅服务器需要出示证书证明自己合法，客户端也需要证书来证明自己是授信用户。

• 物联网设备身份认证：防止非法设备接入网络。

2. 证书的签发过程

根据前面提到的验证过程，证书需要CA机构来签发，才是合法有效的证书。

3. 证书签发的基本步骤

以下以某个服务器（example.com 网站）向 CA 申请证书为例：

1. 生成密钥对

• 服务器管理员在自己机器上生成一对密钥：
  • 私钥（Private Key）
  • 公钥（Public Key）
• 私钥保存在服务器本地，绝不能泄漏。
• 公钥会包含在后续发送给 CA 的申请中。

---

2. 准备证书签名请求 (CSR, Certificate Signing Request)

• 管理员用服务器私钥生成一个 CSR 文件，里面包含：
  • 公钥（服务器用于 TLS 加密的公钥）
  • 域名信息（Common Name, SAN 等）
  • 组织信息（公司名、国家、省市等，取决于证书类型 DV/OV/EV）
• CSR 本身用申请者的私钥签名，以证明确实拥有对应的私钥。

---

3. 将 CSR 提交给 CA

• 管理员把 CSR 提交给受信任的证书颁发机构（CA）。

---

4. CA 验证身份

• 不同类型的证书验证要求不同：
  • DV（域名验证）证书：CA 验证申请人对域名的控制权（例如在域名 DNS 里加一条 TXT 记录，或在网站目录里放文件）。
  • OV/EV 证书：CA 还要验证公司的注册信息、身份信息、甚至电话确认。

---

5. CA 生成证书

• 验证通过后，CA 会用自己的私钥对申请者信息 + 公钥 进行签名，生成证书：
  • 把申请者的公钥、域名信息、有效期等数据打包，
  • 用 CA 的私钥签名。

---

6. 颁发证书给申请者

• 最终的“服务器证书”返回给申请者。
• 服务器管理员把它部署在服务器上（连同自己的私钥）。
• 同时，管理员也要配置 CA 提供的中间证书，以便客户端能组成完整链路。

---

4. 签发流程图

flowchart TDA[服务器生成密钥对] -->|生成后| B[公钥 → 放进 CSR 请求]A --> C[私钥 → 本地保存]B --> D[提交 CSR 给 CA]D --> E[CA 验证申请者身份/域名合法性]E --> F[CA 用自己的私钥对 CSR 信息签名]F --> G[服务器证书<br/>包含: 公钥 + 域名<br/>签名: CA 私钥签名]G --> H[发回给服务器管理员]

5. 总结

• 私钥由申请者生成并保存；
• CSR把公钥+身份信息交给 CA；
• CA 用自己的私钥签名 → 生成申请者的证书；
• 客户端（浏览器）之后就能通过 CA 的公钥（在 CA 证书中） 来验证该服务器证书。

四、自签名证书

自签名证书（Self-signed Certificate） 就是由自己颁发给自己的证书。

• 它的 Subject（主题） = Issuer（颁发者），即颁发方和持有方是同一个。
• 证书里的公钥属于某个实体（比如一台服务器），而签名部分是用该实体自己的私钥生成的。

1. 特点

不依赖外部 CA

• 普通服务器证书是由第三方权威证书机构（CA）签发的。
• 自签名证书则完全自己生成，不需要向 CA 申请。

不被默认信任

• 浏览器、操作系统不会自动信任任意一个自签证书。
• 如果直接访问启用了自签证书的网站，会提示“证书不受信任”。

可以手动信任

• 如果你把自签名证书导入到系统/浏览器的“受信任根证书库”中，它就会像根 CA 一样发挥作用。

2. 自签名证书常见用途

• 开发和测试
  在本地调试 HTTPS 或内部服务器测试时，可以快速生成一个自签名证书。
• 内网环境
  在组织内部使用，不依赖外部 CA，管理员可以自己分发证书并在客户端手动导入信任。
• 加密通信
  即使浏览器提示“不受信任”，自签名证书依然能提供 TLS 加密通道——只不过无法保证通信对方身份可信。

总之，自签名证书是由实体本身生成和签发的证书，它能提供加密，但默认不被浏览器/操作系统信任，常用于测试或内网场景。

3. 根证书和自签名证书的区别

• 根证书

  • 一种权威自签名证书，被操作系统、浏览器事先放进了“受信任的根证书库”里，广泛接受。
  • 因为它在信任库里，所以即使它是自签名的，浏览器仍然会接受它，作为信任链的“第一环”。
  • 根证书是整个公钥基础设施（PKI）的“信任锚点”。

• 自签名证书（自己随便生成的）

  • 虽然它的格式和根证书一样，但没有被任何客户端预先信任。
  • 默认浏览器不信任它，会提示“不受信任的证书”。
  • 你需要手工导入到浏览器/系统的受信任根证书列表里，它才能生效。

• 普通自签证书只在“自己信任的范围”里有效，而根证书的特殊之处在于：它被大量用户端默认预安装和信任。

五、证书认证和数据加密

前面说到，证书认证实质上是为了验证通信的一方或者双方的真实身份，避免被冒用；而且证书的验证是一个信任链验证过程，信任锚点-根证书（CA 证书）在本地浏览器或者操作系统中已经保存了。

对于 ESP32 等物联网单片机，在建立TLS 连接时，需要开发人员提供根证书。

这一个过程，就是TLS所做的事情:

TLS的主要功能：

• 数据加密（机密性 + 完整性）：保证通信内容在传输过程中不被第三方窃听。
• 身份认证：通过证书机制确认通信双方的身份（例如，确认你访问的确实是某个网站而不是钓鱼网站）。

六、TLS 通信建立过程（经典版：TLS 1.2）

TLS 握手的目标：

1. 确认双方身份（通过证书链来验证服务器，部分场景还验证客户端）。
2. 协商安全参数（加密算法、会话密钥）。
3. 生成共享密钥，后续使用对称密钥，进行加密通信。

---

1. 具体流程

2. 关键过程解析

• ClientHello / ServerHello：交换随机数，协商版本和加密套件。
• Certificate：服务器提供证书（包含公钥），供客户端验证其身份。
• ClientKeyExchange：用（EC）DHE 或 RSA 等方法生成共享的会话密钥。
• ChangeCipherSpec / Finished：切换到协商好的对称密钥，验证握手是否成功。
• 之后的应用数据（HTTP、MQTT 等）都基于对称加密传输。

3. 跳过证书（身份）验证

在建立TLS通信过程中，可以通过设置，跳过证书验证环节，TLS 的密钥交换和加密流程仍然会完整执行，依然会建立加密的通信通道。

比较常见的情景就是，我们通过浏览器访问不安全的网站时，可以强制访问，此时通信依然是加密的HTTPS通道。这里的不安全网站，是因为网站的证书没有通过CA机构签发。