根证书与自签名：信任的起点，也是风险的源头

说实话，根证书是整个PKI体系里最特殊的存在。它没有上级给它背书，它自己就是信任的终点。我经常跟团队里的新人说，根证书就像身份证的签发机关——你信它，它下面的所有证书才可信。

这一章我们聊两个核心问题：根证书怎么生成？自签名证书什么时候能用、什么时候千万别用？

根证书的本质：信任的锚点

根证书，也叫CA根证书。它是证书链的顶层，是自签名的——也就是说，它用自己的私钥签自己的公钥。没有上级CA给它发证。

为什么需要根证书？你想想看，如果每张证书都要往上追溯，总得有个尽头。这个尽头就是根证书。浏览器、操作系统里预装的那些根证书，就是各大CA的信任锚点。

核心概念：根证书的信任不是技术问题，是管理问题。技术上任何人都能生成根证书，但要让别人信任它，要么靠预装，要么靠手动导入。

根证书的生成：OpenSSL实战

我个人习惯用OpenSSL来生成根证书。原因很简单：它够底层、够透明，你能看到每一步在做什么。

下面是一个标准的根证书生成流程。注意，根证书的密钥长度我建议至少4096位，有效期可以设长一些——比如10年或20年。因为根证书一旦更换，所有下级证书都得重新签发。

# 1. 生成根CA的私钥（4096位RSA）
openssl genrsa -out root-ca.key 4096

# 2. 生成根CA的证书签名请求（CSR）
openssl req -new \
  -key root-ca.key \
  -out root-ca.csr \
  -subj "/C=CN/O=My Industrial CA/CN=My Root CA 2025"

# 3. 自签名生成根证书（有效期20年）
openssl x509 -req \
  -days 7300 \
  -in root-ca.csr \
  -signkey root-ca.key \
  -out root-ca.crt \
  -extensions v3_ca \
  -extfile <(echo "
[v3_ca]
basicConstraints = critical, CA:TRUE
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
")

这里有几个关键点我要强调一下：

  • basicConstraints = CA:TRUE —— 这是根证书的身份证。没有这个标记，它就不是CA证书。
  • keyUsage = keyCertSign, cRLSign —— 根证书只用来签发下级证书和CRL，不能用来做SSL/TLS服务器证书。
  • subjectKeyIdentifier 和 authorityKeyIdentifier —— 这两个扩展用于证书链的路径构建，建议加上。

我的习惯：生成根证书后，我会立刻把私钥离线存储——最好是拔掉网线的专用加密机或U盾。根私钥泄露，整个信任体系就崩了。我在一个工厂项目里见过有人把根私钥放在共享文件夹里，嗯，那场面……

自签名证书：什么时候用？

自签名证书，说白了就是自己给自己签发的证书。它没有上级CA背书。适用场景其实很明确：

场景 是否推荐 原因
内部测试环境 ✅ 推荐 快速验证，不需要走CA流程
开发阶段的设备通信 ✅ 推荐 原型验证，后续会替换为正式证书
个人学习实验 ✅ 推荐 零成本，理解证书原理
生产环境工业设备 ❌ 不推荐 无法撤销、无法审计、无法自动信任
对外服务的Web/API ❌ 不推荐 浏览器会报不安全，用户不信任
多设备互信场景 ❌ 不推荐 每台设备都要手动导入，管理成本爆炸

生成自签名证书其实很简单，跟根证书的生成步骤几乎一样。区别在于：自签名证书的basicConstraints通常不设CA:TRUE，或者直接设CA:FALSE。

# 生成自签名服务器证书（有效期1年）
openssl req -x509 -nodes \
  -days 365 \
  -newkey rsa:2048 \
  -keyout server.key \
  -out server.crt \
  -subj "/CN=192.168.1.100" \
  -addext "subjectAltName=IP:192.168.1.100"

注意：自签名证书没有CRL分发点和OCSP响应器。一旦私钥泄露，你没办法远程撤销它。唯一的办法是手动删除所有信任该证书的设备上的证书文件。这在工业现场简直是噩梦——几十上百台PLC、HMI、网关，一台台去操作？

自签名证书的风险：我踩过的坑

我曾经在一个水处理项目中接手过一套系统。前任工程师给所有PLC和上位机都用了自签名证书。一开始没什么问题，直到有一台PLC的证书私钥疑似泄露。

问题来了：没法撤销。我们只能把所有设备的证书全部重新生成、重新部署。那是一个周末，我和两个同事在闷热的控制室里，一台台设备连串口、传文件、重启。折腾了整整两天。

从那以后，我对自签名证书的态度就很明确了：

  • 测试用，没问题。 用完就删，别留着。
  • 生产用，绝对不行。 哪怕只是三五台设备，也建议搭一个内部CA。
  • 如果非要用自签名， 至少做好私钥的物理隔离和定期更换计划。

根证书 vs 自签名证书：一张图说清楚

下面这张图展示了根证书和自签名证书在信任链中的位置差异。左边是标准的CA层级结构，右边是自签名证书的孤立状态。

根证书 vs 自签名证书：信任结构对比 CA层级结构（推荐） 根CA（自签名） 中间CA 设备证书 优势 可撤销、可审计、可自动信任 私钥分级保护，风险隔离 自签名证书（不推荐生产） 设备A（自签名） 设备B（自签名） 设备C（自签名） 风险 无法撤销、无法自动信任 私钥分散，管理成本高

什么时候该用根证书+中间CA？

我建议，只要你的工业设备超过3台，或者设备需要对外提供服务，就别用自签名了。搭一个内部CA，成本不高，但收益巨大。

内部CA的好处：

  • 统一信任锚点 —— 所有设备只信任你的根证书，新增设备只需签发证书。
  • 证书可撤销 —— 设备退役或私钥泄露，直接吊销证书，不用一台台去删。
  • 审计追踪 —— 谁签发了什么证书，什么时候签的，都有日志。

我的建议：生产环境至少分两级CA——根CA离线存储，中间CA在线签发。这样即使中间CA被攻破，根CA还在，可以重新签发中间CA，不用重建整个信任体系。

避坑指南：自签名证书的四个「不要」

最后，我总结一下自签名证书的四个「不要」。这些都是我在项目里亲眼见过的教训：

  1. 不要在生产环境用自签名证书做设备身份认证。 一旦需要更换，你会后悔的。
  2. 不要用自签名证书做代码签名。 操作系统和固件更新机制不会信任它。
  3. 不要把自签名证书的私钥放在代码仓库里。 我见过有人把私钥提交到Git，然后整个项目组都能下载……
  4. 不要以为自签名证书「够用就行」。 今天够用，明天设备多了、安全要求高了，改起来成本翻倍。

嗯，根证书和自签名证书的话题就聊到这里。记住一句话：根证书是信任的起点，自签名证书是信任的孤岛。选哪个，看你想要的是桥梁还是独木舟。

← 上一章 📖 返回目录 下一章 →