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

数字签名与证书

[一、什么是数字签名（Digital Signature）](#一、什么是数字签名（Digital Signature）)
[二、什么是数字证书（Digital Certificate）](#二、什么是数字证书（Digital Certificate）)
- [1. 数字证书（典型的 X.509 证书）主要包含](#1. 数字证书（典型的 X.509 证书）主要包含)
- [2. 证书和密钥的关系](#2. 证书和密钥的关系)
- [3. 证书的后缀](#3. 证书的后缀)
- [4. ESP32中的证书](#4. ESP32中的证书)
[三、证书认证（Certificate Authentication）](#三、证书认证（Certificate Authentication）)
- [1. 证书认证的原理](#1. 证书认证的原理)
- [2. 证书的签发过程](#2. 证书的签发过程)
- [3. 证书签发的基本步骤](#3. 证书签发的基本步骤)
- [4. 签发流程图](#4. 签发流程图)
- [5. 总结](#5. 总结)
四、自签名证书
- [1. 特点](#1. 特点)
- [2. 自签名证书常见用途](#2. 自签名证书常见用途)
- [3. 根证书和自签名证书的区别](#3. 根证书和自签名证书的区别)
五、证书认证和数据加密
[六、TLS 通信建立过程（经典版：TLS 1.2）](#六、TLS 通信建立过程（经典版：TLS 1.2）)
- [1. 具体流程](#1. 具体流程)
- [2. 关键过程解析](#2. 关键过程解析)
- [3. 跳过证书（身份）验证](#3. 跳过证书（身份）验证)

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

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

用私钥签名、公钥验证

过程：

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

作用：

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

其中：

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

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

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

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

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

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

作用

身份认证 ：确认通信对方的真实身份（如访问一个HTTPS 网站时，浏览器会检查网站证书），防止中间人攻击 。
访问控制： 根据设备身份和权限，控制设备对资源的访问。

举个例子：

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

使用 openssl 命令可以提取根证书信息：

c 复制代码

openssl x509 -in server_root_cert.pem -text -noout

2. 证书和密钥的关系

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

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

使用时：

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

3. 证书的后缀

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

本质上：PEM 与 CRT 没有"内容上的冲突"，都可以存放 X.509 证书。
差别在于：
- .pem → 强调文件存储格式：Base64 编码 + 文本头尾。
- .crt / .cer → 强调文件功能：这是"证书文件"。
在实际使用中，扩展名只是习惯 ，而不是强制标准。你完全可能遇到 .crt 文件里内容其实是 PEM 格式的。
ESP32 常用 .pem 文件 → 强调文件存储格式，因为框架喜欢"纯文本"证书，容易加载/硬编码。
浏览器常用 .crt 文件 → 强调文件功能，因为这是 OS/浏览器生态里管理证书的通用习惯。

4. ESP32中的证书

ESP32 场景：
ESP32 会用事先烧录/配置的根证书（Root CA）来校验证书链。这个根证书就是"信任的起点"，ESP32 相信它，就间接信任所有它签发的下级证书（中间 CA、服务器证书）。

在 ESP-IDF 里，常见的做法是把根证书（PEM 格式）以字符串常量存到 Flash，然后在 esp_tls_cfg_t 配置里传进去。

如果服务器证书续签，但仍由同一个 CA 签发，只要 CA 的根证书没变，ESP32 不需要更新内置的根证书。

但如果换了一个新的签发 CA，就必须在 ESP32 内置新的根证书，否则验证失败。

三、证书认证（Certificate Authentication）

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

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

1. 证书认证的原理

证书颁发 ：用户或服务器先向权威认证机构（CA）申请数字证书。CA 会验证其身份后通过 私钥签名签发证书。
证书验证流程：
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 申请证书为例：

生成密钥对

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

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

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

将 CSR 提交给 CA

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

CA 验证身份

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

CA 生成证书

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

颁发证书给申请者

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

4. 签发流程图

flowchart TD A[服务器生成密钥对] -->|生成后| B[公钥 → 放进 CSR 请求] A --> C[私钥 → 本地保存] B --> D[提交 CSR 给 CA] D --> E[CA 验证申请者身份/域名合法性] E --> F[CA 用自己的私钥对 CSR 信息签名] F --> G[服务器证书
包含: 公钥 + 域名
签名: 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. 具体流程

客户端服务器 ClientHello (协议版本、随机数、加密套件列表...) ServerHello (选择的协议版本、随机数、加密套件) Certificate (服务器证书链，供客户端验证) (可选) CertificateRequest (要求客户端提供证书) ServerHelloDone ClientKeyExchange (用于协商会话密钥) (可选) Certificate (如果服务器要求客户端证书) ChangeCipherSpec (客户端表示切换到加密模式) Finished (客户端用新密钥加密的校验消息) ChangeCipherSpec Finished 双方进入加密通信通道客户端服务器

2. 关键过程解析

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

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

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

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