4. 企业证书生命周期管理

企业代码签名证书与个人开发者证书最大的区别，不在于算法强度，而在于它是一套受治理的组织资产。一张企业 EV 代码签名证书背后通常绑定的是公司法人主体、统一社会信用代码、经过 CA 严格核验的组织信息，以及一枚受硬件保护的私钥。因此，它的生命周期不能由某一个人“顺手管一下”，而必须被拆解为可审计、可追责、可交接的阶段，并明确每个阶段谁申请、谁审批、谁执行、谁复核。

本节把企业证书生命周期划分为六个阶段：申请、审批、签发、部署、续期、吊销。需要强调的是，这六个阶段不是线性走完就结束——续期会回到签发，吊销可能在任何阶段被触发，部署环节还可能因人员离职、构建机迁移而重新进入申请流程。理解这种“带回路”的结构，比记住阶段名称更重要。

一、六个阶段的核心动作与产出

申请阶段的输入是业务需求：某个产品线需要发布 Windows 安装包、驱动或 macOS 应用，需要代码签名。申请人应提交的信息包括：证书用途（签名对象类型）、绑定主体（公司或子公司）、密钥保护方式（HSM 还是硬件令牌）、预计签名频率、需要接入的 CI/CD 系统。产出是一份证书申请表，而不是直接向 CA 下单。

审批阶段解决“该不该发、发给谁、用多久”。审批人通常由安全团队或 PKI 管理员担任，关注点包括：申请主体是否与营业执照一致、用途是否属于公司授权范围、密钥保护是否满足基线要求、是否已有同类证书可复用。审批结论应记录为“批准 / 驳回 / 补充材料”，并留下审批人和时间戳。

签发阶段由 CA 完成主体核验、密钥生成（或接收 CSR）、证书签发。企业 EV 证书通常要求私钥在 FIPS 140-2 Level 2 及以上的 HSM 或硬件令牌中生成，私钥不可导出。产出是证书文件（.cer/.crt）、证书链和可能的中间证书。

部署阶段把证书和私钥接入实际签名环境。常见形态有三种：接入 CI/CD 构建机、接入签名服务器（集中式签名服务）、接入开发者本地硬件令牌。部署时必须记录：证书序列号、指纹、部署位置、生效时间、操作人。

续期阶段不是“到期前再申请一次”这么简单。企业证书续期往往需要重新核验组织信息，且新旧证书可能并行一段时间。续期窗口、并行期、切换点都需要提前规划，否则会出现“旧证书已过期、新证书还没部署”的签名中断。

吊销阶段是生命周期的“紧急出口”。触发条件包括：私钥疑似泄露、硬件令牌丢失、签名人员离职且权限未回收、证书信息变更、CA 要求吊销等。吊销后必须同步更新 CRL/OCSP 依赖方，并检查已发布软件是否受影响。

二、责任矩阵：谁在哪个阶段说了算

上图下半部分给出了一份简化的 RACI 责任矩阵。这里的关键不是把格子填满，而是让每个阶段都有唯一的“A”（最终批准人）。例如审批阶段的 A 是安全/PKI 管理员，签发阶段的 A 是 CA，部署阶段的 A 是安全团队而 R 是运维/构建团队。如果审批和部署都由同一个人既当 R 又当 A，就失去了制衡，审计时会被直接质疑。

实际落地时，建议把矩阵固化为一张可填写的表单，每个阶段至少记录：阶段名称、R 责任人、A 批准人、C 咨询对象、I 知会对象、输入物、输出物、完成判据。下面给出一个可直接参考的示例结构：

阶段       R责任人        A批准人        输入物              输出物              完成判据
申请       业务方         安全/PKI       业务需求说明         证书申请表          申请表字段完整
审批       安全/PKI       安全负责人     证书申请表           审批结论            批准/驳回/补充
签发       CA              CA             审批结论+CSR         证书+证书链         指纹与序列号登记
部署       运维/构建       安全/PKI       证书+私钥保护设备    签名环境配置        签名测试通过
续期       PKI管理员       安全负责人     到期提醒+新CSR       新证书+切换记录     新旧并行期结束
吊销       安全事件响应    安全负责人     事件报告             吊销确认+CRL更新    依赖方验证失效

三、续期与吊销：最容易被忽视的两个环节

续期最容易出问题的地方是并行期管理。假设证书 A 在 2025-06-30 到期，新证书 B 在 2025-06-01 签发。如果 6 月 1 日就立刻把构建机切到 B，那么 6 月 1 日之前已经用 A 签名的安装包在 6 月 30 日之后仍然有效，但新构建的包全部用 B。这本身没问题，问题在于：如果某些老版本软件需要重新签名，而 A 的私钥已经不在构建机上，就会卡住。因此并行期内应保留 A 的签名能力，直到确认没有重签需求。

吊销则要区分“主动吊销”和“被动吊销”。主动吊销是计划内的，比如人员离职、证书用途变更；被动吊销是事件驱动的，比如私钥泄露。无论哪种，吊销后都要做三件事：第一，向 CA 提交吊销请求并确认生效；第二，检查 CRL/OCSP 响应是否已更新；第三，评估已发布软件是否因吊销而出现签名验证失败。特别是时间戳签名（RFC 3161）的存在，使得已签名的旧软件在证书吊销后仍可能保持有效——这一点必须在事件响应流程中明确判断，不能一刀切地认为“吊销后所有签名都失效”。

四、把流程落到可审计的记录上

企业证书生命周期管理的最终交付物不是一张证书，而是一套可追溯的记录链。每个阶段至少应留下：时间戳、操作人、操作对象（证书序列号/指纹）、操作类型、审批依据。推荐使用一个简单的证书台账，字段包括：证书名称、主体、序列号、指纹（SHA-256）、签发日期、到期日期、密钥保护方式、部署位置、当前状态、责任人、最近一次操作记录。

当审计或安全事件发生时，这张台账能让你在几分钟内回答三个问题：这张证书现在在哪、谁在管、如果现在要吊销会影响哪些系统。这比任何流程文档都更有说服力。流程是给人看的，台账是给审计和应急用的，两者缺一不可。