安全
OPC UA 安全与证书
安全性内建于 OPC UA，而非事后加装。连接会协商一个安全策略和安全模式，然后客户端与服务器用 X.509 证书互相认证。理解这两个概念（模式与信任）就能解决大多数安全问题和连接故障。
四大支柱
| 支柱 | 它保护什么 |
|---|---|
| 加密 | 机密性：没人能读取流量 |
| 签名 | 完整性：消息无法被篡改 |
| 身份验证 | 身份：应用程序的身份（证书）和用户的身份 |
| 授权 | 权限：已认证用户可以做什么 |
安全模式
- None：不签名、不加密。仅用于隔离的测试环境。
- Sign：消息被签名（完整性 + 认证）但不加密。
- Sign & Encrypt：签名并加密。生产环境使用这一种。
每种模式都与一个安全策略（密码套件，例如 Basic256Sha256 或较新的 Aes256 系列策略）配对。优先使用现代策略，并禁用已废弃的策略。
证书信任是怎么运作的
每个 OPC UA 应用都有自己的实例证书。连接时，客户端与服务器交换证书；各自保存一个小的 PKI 存储：
pki/
├─ own/ # this application's own cert + private key
├─ trusted/certs # certificates we trust
├─ trusted/crl # certificate revocation lists
├─ issuer/ # CA certs (if using a CA)
└─ rejected/ # certs seen but not yet trusted典型的首次连接失败：对端的证书落在
rejected/。把它移到trusted/certs在两端都完成，然后重新连接。仅这一步就能解决大多数“BadSecurityChecksFailed”错误。自签名 vs CA 签名
自签名证书适用于小规模、静态的部署：你逐个手动信任。对于设备群，证书颁发机构（或 OPC UA GDS：Global Discovery Server）可以扩展信任：只需信任 CA 一次，它签发的每一张证书都会被自动信任。
用户身份验证
应用（证书）身份与用户身份是分开的。服务器可以接受匿名、用户名/口令或用户证书令牌。请与服务器的期望相匹配，并在生产环境中优先使用具名用户而非匿名，使操作可追溯到人。
加固检查清单
- 使用Sign & Encrypt并搭配现代策略；禁用 None 和已废弃的策略。
- 用受管证书替换默认/自签名证书；设置合理的有效期并定期轮换。
- 要求使用具名用户；尽可能禁用匿名访问。
- 实行最小权限授权：除非确实需要写入，否则一律只读。
- 保持 CRL 更新；从
trusted/中移除过期证书。 - 把 OPC UA 放在分段网络上；把端口限制给已知客户端。
- 给你的 OPC UA 协议栈打补丁：把它当作任何其他联网服务对待。
此刻正卡在握手错误上？跳到连接故障排查.
最后更新于 2026 年 9 月 4 日 · 教育资源。