sign-pki · 核心流程

1. 初始 CA 资产生成

推荐使用 pki-cli bundle generate，让 Catalog 明确描述组织、Key、有效期和签发关系。

执行前，所有目标必须引用不同的 KMS Key SKI；Access Token 由各 pinEnv 环境变量注入。工具不会创建、备份、轮换或删除 HSM Key。

2. 单银行加入

标准流程是“私钥留在银行，CSR 进入审批，Root 只返回公开证书”：

1. 银行在本行 HSM 中分别生成 Identity 与 TLS Intermediate CA Key。
2. 银行使用 pki-cli ca csr 生成两份固定策略 CSR。
3. 央行核验 CSR 签名、公钥指纹、Subject、用途和审批记录。
4. 央行在离线域使用 pki-cli ca sign 与对应 Root Key 签发证书。
5. 银行用 pki-cli verify --profile intermediate-ca 或 bundle verify 验证交付物。
6. 银行部署两个在线 Fabric CA，并创建最小权限 Registrar/Revoker。
7. 银行只向联盟提交公开 MSP、TLS CA 链和节点端点；联盟另行完成配置与策略审批。

PKI 签名不等同于网络准入。央行默认不得收集银行 CA Key、Registrar 私钥或 Enrollment Secret。

3. CA Server 启动

正式环境在开放 Service 前必须完成 HTTPS/mTLS 和 Operations mTLS 验证。TLS Intermediate CA 的一次性 HTTP 自举是唯一例外，且只能监听回环地址、单副本运行、无外部入口。

4. 叶子证书生命周期

普通 TLS、mTLS、Fabric MSP 与应用身份由标准 Fabric CA API 管理，不由 pki-cli 签发：

Register → Enroll → 使用 → Reenroll → 发布/滚动 → Revoke → CRL

• Registrar 权限由 Enrollment Certificate、请求签名和 hf.* 属性控制。
• TLS Server CSR 必须包含实际访问 DNS/IP SAN。
• 叶子证书续期通常不改变 Root/Intermediate 信任锚。
• Orderer TLS 续期优先复用原私钥；更换私钥前必须评估网络配置绑定。

ca-server/e2e 以标准 HTTP wire 协议覆盖 CAInfo、Admin/User Enroll、Register、证书链验证、Reenroll、身份查询、Revoke 与 CRL，验证在线 CA 到 KMS/HSM 的真实签名链路。

5. CA 换代

Root 或 Intermediate CA 不允许原地覆盖，必须双信任迁移：

1. 生成新 CA Key 和证书。
2. 将新旧 CA 同时发布到 MSP 与 TLS 信任配置。
3. 确认全网信任传播完成。
4. 由新 CA 签发并滚动叶子证书。
5. 完成兼容、签名、TLS 与恢复验证。
6. 宽限期后移除旧 CA，并按策略发布 CRL/停用信息。

Wallet Idemix Issuer/Revocation Key 的换代属于新的参数版本迁移，不能只替换私钥引用。

6. Bundle 核验与防篡改

pki-cli bundle verify 同时核验：

• 顶层和各目标 checksums.sha256；
• manifest.json 的 Catalog、目标、组织、信任域与用途；
• 允许的文件集合；
• Root / Intermediate 固定策略、SKI 和签名链；
• Wallet CA 不进入 Network MSP 的标记。

生成过程使用 staging 目录，全部成功后才原子发布；默认拒绝覆盖已有输出，避免半成品被误当成有效交付。