4. 证书管理：应用实例证书、CA 证书与信任列表
证书管理，说白了就是解决「你是谁、你凭什么、我信不信你」这三个问题。OPC UA 的加密会话能不能跑起来，一半的功夫都在证书管理上。我见过太多项目，加密算法配得再强，证书管理一塌糊涂，最后还是裸奔。
这一章我们聚焦三个核心概念：应用实例证书、CA 证书和信任列表。搞懂它们，你就能自己搭一套靠谱的证书体系。
4.1 应用实例证书：每个 OPC UA 应用的身份证
每个 OPC UA 应用（无论是客户端还是服务器）在启动时，都会生成或加载一个应用实例证书。这个证书是 X.509 v3 格式，里面包含了应用的公钥、名称、URI、有效期等信息。
我个人习惯把应用实例证书比作「身份证」。你想想看，两个人见面，先亮身份证，确认对方不是冒牌的。OPC UA 握手时也是这样——双方交换证书，互相验证。
应用实例证书的关键字段：
- Subject：应用的身份标识，比如 CN=MyOPCUAServer
- SubjectAltName：应用 URI 和主机名，用于网络级验证
- Validity：有效期，默认通常是一年或五年
- Key Usage：数字签名、密钥加密等用途标记
我记得有一次在现场调试，服务器证书的 SubjectAltName 里写的是 localhost，结果客户端用真实 IP 去连接，握手直接失败。嗯，这种坑踩过一次就记住了。
4.2 CA 证书：谁来给你发身份证？
应用实例证书可以自签名，也可以由 CA（证书颁发机构）签发。自签名证书就像自己给自己印名片，别人信不信全看缘分。CA 签发的证书则像公安局发的身份证，有公信力。
在工业现场，我建议你搭建自己的 CA。为什么？因为自签名证书在设备数量超过 10 台时，管理成本会爆炸。你想想看，每台设备都要手动交换证书、互相导入信任列表，50 台设备就是 2500 次信任关系配置——这谁受得了？
| 对比项 | 自签名证书 | CA 签发证书 |
|---|---|---|
| 部署复杂度 | 低（单台设备） | 中（需搭建 CA） |
| 信任管理 | 点对点，N² 复杂度 | 链式信任，N 复杂度 |
| 吊销能力 | 无 | 支持 CRL/OCSP |
| 适用场景 | 测试、单机 | 生产环境、多设备 |
CA 证书的核心作用就是签发和验证。你只需要把 CA 证书分发给所有设备，设备之间就能通过 CA 证书链互相验证身份。我曾经帮一个客户从自签名迁移到 CA 体系，信任配置从 3 天缩短到 1 小时。
4.3 信任列表：谁可以跟我说话？
信任列表（Trust List）是 OPC UA 应用用来决定「我信任谁」的清单。它本质上是一个证书存储区，里面放着你信任的 CA 证书或直接信任的应用实例证书。
OPC UA 的信任模型有两种：
- 直接信任：把对方的应用实例证书直接加入信任列表。适合设备少、关系固定的场景。
- 链式信任：只信任 CA 证书，由 CA 来担保应用实例证书的合法性。适合大规模部署。
我的建议：生产环境优先用链式信任。直接信任虽然简单，但证书过期或更换时，你得去每台设备上更新信任列表。链式信任只需要更新 CA 证书，应用实例证书随便换，只要 CA 没变，信任关系就还在。
4.4 证书生命周期管理
证书不是配好就完事的。它有生命周期：生成、分发、使用、续期、吊销。我见过最惨的案例是，客户的生产线跑了两年，突然所有 OPC UA 连接都断了——因为证书过期了。
证书生命周期的主要阶段：
- 生成：应用启动时自动生成，或通过工具预生成
- 分发：把证书部署到目标设备
- 验证：握手时验证证书链和有效期
- 续期：在证书过期前重新签发
- 吊销：证书泄露或设备退役时，将其加入 CRL
警告：千万不要在生产环境使用默认的自签名证书。很多 OPC UA 服务器出厂时带一个固定的测试证书，公钥是公开的。我曾经在安全审计时发现，某工厂 200 台设备用的全是同一个默认证书——等于所有设备的「身份证」一模一样，攻击者拿到一个就能伪装成任意一台。
4.5 证书存储与目录结构
OPC UA 规范定义了标准的证书存储目录结构。不同平台实现可能略有差异，但核心目录是一致的：
PKI/
├── own/ # 自己的证书和私钥
│ ├── cert.der # 应用实例证书
│ └── private.pem # 私钥（权限保护）
├── trusted/ # 信任的证书
│ ├── ca.crt # 信任的 CA 证书
│ └── apps/ # 直接信任的应用证书
├── rejected/ # 验证失败的证书（审计用）
└── crl/ # 证书吊销列表
└── ca.crl # CA 签发的吊销列表这个目录结构我建议你严格遵循。为什么？因为很多 OPC UA 栈（比如 open62541、UaExpert）默认就按这个路径找证书。你改了路径，就得改配置，改配置就容易出错。
4.6 证书验证流程
理解了上面的概念，我们来看看实际握手时证书是怎么验证的。下面这张图展示了完整的验证流程：
验证流程其实就三步：
- 有效期检查：证书是否在有效期内？过期了直接拒掉。
- 证书链验证：从应用证书到根 CA，逐级验证签名。只要有一级签名不对，整条链就断了。
- 信任列表匹配：根 CA 或应用证书是否在信任列表中？不在的话，即使证书本身合法，也不予信任。
我曾经遇到过一个诡异的问题：证书链验证通过了，但握手还是失败。查了半天，发现是信任列表里只放了 CA 证书，但 CA 证书的 Key Usage 没有标记为「证书签名」——CA 证书自己就不合法。嗯，这种细节最容易忽略。
4.7 避坑指南
我曾经踩过的坑：
- 证书时间不同步：设备时间差了 5 分钟，证书验证直接失败。后来我强制所有设备用 NTP 同步时间。
- 私钥权限过大：私钥文件权限设为 777，被安全扫描工具报高危。私钥应该只有 OPC UA 进程用户能读。
- 证书重用：开发环境的证书直接拿到生产环境用，结果证书里的 URI 和生产环境不匹配，握手失败。
- 忘记配置 CRL：证书吊销列表不配置，泄露的证书还能继续用。这相当于门锁坏了但不换。
证书管理看起来琐碎，但它是 OPC UA 安全体系的基石。你花 80% 的精力把证书管好，剩下 20% 的加密配置就水到渠成。下一层我们聊聊会话建立时的具体加密握手过程——到时候你会看到，证书管理做得越好，握手就越顺畅。