网络笔记：PKI 体系与证书——公钥怎么才可信

上一篇讲到，DH 密钥交换本身不认证身份，会被中间人攻击。要解决这个问题，就得回答一个更基础的问题：我怎么确定手上这把公钥真的是对方的？

PKI（Public Key Infrastructure，公钥基础设施）就是为这个问题而生的一整套体系。

一句话概括：证书 = 公钥 + 身份信息 + 有效期 + CA 的签名。它把「公钥」和「身份」绑在一起，而绑定的动作由大家都信任的第三方（CA）完成。

PKI 的组成

PKI 的四个组成部件、证书的申请签发流程与验证要点 — ▲ PKI 的四个部件与证书的一生

部件	职责	关键点
CA（认证中心）	签发证书、吊销证书	整个 PKI 的信任锚。它的私钥是整个体系里最需要保护的东西
RA（注册中心）	受理申请、审核申请人身份	把「审核」和「签发」分开，降低 CA 私钥暴露风险
证书库	存放已签发的证书	通常是 LDAP 或 HTTP 目录服务
CRL（吊销列表）	记录被提前作废的证书	相当于「黑名单」，要定期下载更新
终端	生成密钥对、申请、使用证书	私钥永远不离开本机——只把公钥交出去

证书里到底装了什么

标准是 X.509（现在都是 v3）。核心字段：

X.509 v3 结构

┌─────────────────────────────────────────────────────┐
│ 版本            v3                                   │
│ 序列号          由 CA 分配，唯一                      │
│ 签名算法        CA 用哪个算法签的（如 SHA256-RSA）     │
├─────────────────────────────────────────────────────┤
│ 颁发者 Issuer   CA 的名字（"谁签的我"）               │
│ 有效期          生效时间 ~ 失效时间                    │
│ 主体 Subject    "我是谁"（CN/O/OU/C 等）              │
│ 主体公钥信息     ★ 我的公钥 + 算法                     │
│ 扩展            用途限制、CRL 地址、密钥用法等          │
├─────────────────────────────────────────────────────┤
│ CA 的签名       ★ CA 用自己私钥对以上所有内容做的签名   │
└─────────────────────────────────────────────────────┘

★ 改任何一个字段 → 签名对不上 → 证书作废
★ 这就是"不可伪造"的来源

注意：证书里没有私钥，只有公钥。私钥是申请方自己生成的，从头到尾没出过本机——这是设计上的关键，CA 也不知道你的私钥。

证书怎么申请

流程就是上一篇讲的「生成密钥对 → 提交申请 → CA 签发 → 部署使用」。协议层面对应的是 SCEP（Simple Certificate Enrollment Protocol），网络设备（路由器、防火墙）申请证书基本都用它。

步骤	谁做	做什么
1	终端	本地生成 RSA/ECC 密钥对，私钥不出本机
2	终端	把「公钥 + 身份信息（CN/O/C）」打包成 PKCS#10 请求，发给 RA
3	RA	审核申请人身份（人工或自动策略）
4	CA	用 CA 私钥对请求内容签名，生成 X.509 证书
5	终端	取回证书，和本地私钥配对使用

信任链：为什么一张证书就能被信

现实中不会用「根 CA 直接签所有设备证书」，而是分层：

证书链

        根 CA（Root CA）
        自签名，公钥预置在设备里 —— 这是【信任锚】
              │ 用根 CA 私钥签
              ▼
        子 CA / 中间 CA（Sub CA）
              │ 用子 CA 私钥签
              ▼
        设备证书（Router-1 / Firewall-1 …）

验证时从下往上追：
  设备证书 ──用子CA公钥验签──► 子CA证书 ──用根CA公钥验签──► 根CA证书
                                                          └─ 自签名，公钥是预置的 → 到此为止

★ 链上任何一环断掉，验证就失败
★ 这就是为什么"证书导入不全"是 PKI 排错的高频问题
★ 根 CA 的私钥通常离线保存，签发子 CA 证书时才拿出来

吊销：CRL 与 OCSP

证书有有效期，但有效期内的证书也可能需要提前作废（私钥泄露、员工离职、设备报废）。这就靠吊销机制。

	CRL	OCSP
全称	Certificate Revocation List	Online Certificate Status Protocol
形式	CA 定期发布的列表文件	逐个证书在线查询
优点	一次下载可离线校验，不依赖实时网络	实时性高，不用下载整个列表
缺点	有更新延迟（列表发布周期）；列表会越来越大	每次验证都要联网，依赖 OCSP 服务器可用性
华为设备	配 `crl-url` 定期下载	支持，但设备侧更常用 CRL

华为设备 PKI 配置

huawei vrp · PKI + SCEP 自动申请

# ① 配置 PKI 域（realm）——告诉设备去哪找 CA
pki realm mycorp
 ca id 1
  enrollment-url http://10.1.1.100/certsrv/mscep/mscep.dll   # CA 的 SCEP 服务地址
  fingerprint sha256 A1B2C3...                                # ★ 校验证书指纹，防中间人
  crl-url http://10.1.1.100/CertEnroll/mycorp-root.crl        # 吊销列表地址

# ② 本地生成密钥对
rsa key-pair label mykey modulus 2048

# ③ 配置实体信息（决定证书里的"我是谁"）
pki entity myentity
 common-name Router-1
 country CN
 organization MyCorp
 organization-unit IT

# ④ 申请证书（SCEP 自动走完申请-审核-签发）
pki enroll-certificate realm mycorp entity myentity key-pair mykey

# ⑤ 验证
display pki certificate realm mycorp        # ★ 本地已有证书
display pki realm mycorp                    # realm 配置与状态
display rsa key-pair label mykey            # 本地密钥对

enrollment-url 的具体路径取决于 CA 服务端。用 Microsoft AD CS 的话就是 certsrv/mscep/mscep.dll；用第三方 CA 要按厂商文档填。

几个容易踩的坑

时间不对，什么都验不过。证书验证要检查有效期，设备时钟错了（比如从 2000 年开始），证书直接判为无效。这几乎是 PKI 排错第一坑——先 display clock 看一眼；
证书链不全。只导入了设备证书，没导入 CA 证书 → 验签失败。导入时要「设备证书 + 子 CA + 根 CA」整套；
CN 不匹配。IPSec 场景里如果对端用 IP 地址标识，证书的 CN 或 SAN 里要有这个 IP，否则身份校验不过；
忘了配 CRL。不配 CRL 校验的话，被吊销的证书依然能用，安全性打折；
指纹没校验。申请时如果没配 fingerprint，理论上存在被假 CA 欺骗的可能。

一句话总结：PKI 解决的从来不是「保密」，而是「可信」。它用 CA 的签名把公钥和身份绑定，用证书链把信任传递下来，用 CRL/OCSP 处理「提前作废」。保密那件事，还是交给对称加密。这两件事合在一起，才是 IPSec、HTTPS、SSH 这些协议的完整底子。

📌 本篇整理自 2024–2025 的「数通」学习笔记（HCIE-Datacom 方向）

合并了原始笔记中「PKI / PKI体系架构」两页。
原笔记以 PKI 组件图和申请流程图为主，本文补齐了 X.509 字段结构、证书链的逐级验证过程、CRL 与 OCSP 的取舍，以及设备时钟、证书链不全这两个实际项目高频问题。
配置命令按华为 VRP 语法整理，enrollment-url 需按实际 CA 服务端调整。