4、密码学基础（下）：数字签名、数字证书、PKI体系、证书链验证流程

上一讲我们把对称加密、非对称加密和哈希函数聊透了。这一讲，咱们得把这些零件组装起来，看看真实世界里到底怎么用。

你想想看，光有非对称加密够不够？我拿公钥加密一段数据发给你，你能解密，但你怎么确定这公钥真的是我的？万一中间人换掉了呢？这就是数字签名和证书体系要解决的问题。

4.1 数字签名：不只是加密的反向操作

很多人以为数字签名就是「用私钥加密，用公钥解密」。嗯，这个说法在思路上没错，但实际工程里没人这么干。

非对称加密太慢了。你想想，一个几百兆的固件包，用私钥逐字节加密？那得等到天荒地老。所以真实做法是：

1. 对原始数据做哈希，得到摘要（比如 SHA-256）。
2. 用私钥加密这个摘要，得到签名。
3. 把原始数据和签名一起发出去。

验证方拿到数据后，用公钥解密签名得到摘要A，再自己对数据做哈希得到摘要B。两个摘要一比对，一致就说明数据没被篡改，而且确实是你签的。

我在项目里遇到过一件事。有个同事把签名和加密搞混了，直接用私钥加密了整个固件包。结果网关升级时，解密一次要花40秒，用户直接投诉。后来改成先哈希再签名，整个验证过程降到毫秒级。这个坑，我建议你别踩。

4.2 数字证书：把公钥和身份绑在一起

好，现在你会签名了。但问题来了——你怎么证明你手里的公钥就是我的？

数字证书就是干这个的。它本质上是一个结构化的数据文件，里面绑定了三样东西：

• 主体信息：谁的证书（比如设备序列号、组织名称）。
• 公钥：这个主体对应的公钥。
• 签发者签名：谁担保这个绑定关系是真的。

最常见的证书格式是 X.509 v3。我带你看看它长什么样：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0x12345678
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=边缘网关根CA, O=IoT Corp
        Validity
            Not Before: Jan  1 00:00:00 2025 GMT
            Not After : Dec 31 23:59:59 2025 GMT
        Subject: CN=gateway-001, O=IoT Corp
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
    Signature Algorithm: sha256WithRSAEncryption
         Signature Value: a1b2c3d4...

注意看那个 Issuer 和 Subject。Issuer 是签发者，Subject 是持有者。如果两者相同，这就是一张自签名证书——也就是根证书。

4.3 PKI体系：信任是怎么传递的

一张证书好办，但物联网里可能有几十万台设备。难道每台设备都要跟CA建立一次信任？

这就是 PKI（公钥基础设施）要解决的问题。它是一整套策略、流程和软件的组合，核心就是「信任链」。

典型的 PKI 层级长这样：

为什么要搞这么多层？直接根CA签设备不行吗？

行，但风险太大。根CA的私钥一旦泄露，整个体系就崩了。分层之后，根CA可以离线保存，平时只用二级CA或三级CA来签发设备证书。就算三级CA的私钥丢了，吊销它就行，根CA不受影响。

4.4 证书链验证流程：一步步往上查

现在假设你的边缘网关收到了一个来自云平台的连接请求，对方出示了一张证书。你怎么验证它？

流程其实不复杂，我拆成五步：

1. 拆解证书链：把收到的证书、中间CA证书、根证书按顺序排好。
2. 验证签名：用上一级证书的公钥，验证下一级证书的签名。说白了就是「子证书的签名是不是父证书签的」。
3. 检查有效期：每张证书的 Not Before 和 Not After 必须包含当前时间。
4. 检查吊销状态：通过 CRL（证书吊销列表）或 OCSP（在线证书状态协议）确认证书没被吊销。
5. 检查用途：证书的 Key Usage 和 Extended Key Usage 必须匹配当前使用场景。

我画个流程图，你一看就明白：

这里面最容易出问题的是第4步——吊销检查。很多边缘网关为了省流量，直接把这一步跳过了。结果设备证书被吊销了，网关还在傻傻地信任它。

4.5 边缘网关场景下的特殊考量

通用PKI体系讲完了，但边缘网关有它自己的脾气。我列几个你在实验室里可能想不到的点：

场景	问题	解决方案
离线环境	网关无法联网，查不了CRL/OCSP	预置短期证书（有效期7天），到期前联网续签
计算资源受限	RSA 2048签名验证耗时太长	使用ECC证书（P-256），验证速度快3-5倍
证书存储安全	私钥存在Flash里容易被读走	使用安全芯片（SE）或TEE存储私钥
批量签发	十万台设备逐台签发太慢	使用工厂预置证书，或PKCS#12批量导入

我记得有一次帮客户做网关安全审计。他们的设备证书有效期设了10年，私钥直接明文存在文件系统里。我说这跟没锁门有什么区别？后来帮他们改了方案：证书有效期缩到90天，私钥挪到SE芯片里，再加上OCSP Stapling。整改完之后，客户自己又做了一次渗透测试，说「这次是真的啃不动了」。

4.6 实操：用OpenSSL模拟证书链验证

光说不练假把式。我带你用 OpenSSL 走一遍完整的证书链验证。假设你已经有根CA和二级CA的证书：

# 1. 查看设备证书的签发者
openssl x509 -in device.crt -noout -issuer -subject

# 2. 验证设备证书是否由二级CA签发
openssl verify -CAfile ca-intermediate.crt device.crt

# 3. 验证完整证书链（根CA + 二级CA + 设备）
cat ca-root.crt ca-intermediate.crt > chain.crt
openssl verify -CAfile chain.crt device.crt

# 4. 如果验证失败，查看详细错误
openssl verify -CAfile chain.crt -verbose device.crt

输出结果里，如果看到 error 20 at 0 depth lookup: unable to get local issuer certificate，说明你没把根证书加到信任列表里。如果看到 error 10 at 1 depth lookup: certificate has expired，那就是证书过期了。