代码签名证书 + HSM方案

环度小编：xadmin

代码签名证书 + HSM 是一套已经比较成熟的方案。公开信任代码签名证书的私钥，通常必须放在符合要求的硬件里，例如硬件令牌或合规 HSM，而不是普通文件或软件密钥库。CA/B Forum 的代码签名基线要求持续更新，主流 CA 也明确要求私钥受硬件保护，常见门槛是 FIPS 140-2 Level 2 / 更高 或等效标准。

我们为企业通常提供三种方案，具体落地请请联系 400-9989-115

1. USB Token 方案
最简单，适合 1 到 3 个签名人、签名频率低的团队。证书私钥直接存放在硬件令牌里，人工插入设备执行签名。优点是成本低、落地快；缺点是自动化差、权限审计弱、CI/CD 集成差。主流 CA 现在都支持这种模式。

2. 本地 HSM 方案
适合中大型企业、内网发布、需要强审计和分权审批。做法是把代码签名私钥生成并保存在机房 HSM 中，通过 PKCS#11、Microsoft KSP/CNG 或厂商 API 给签名服务器调用。优点是密钥不出硬件、权限可细分、能接审批流；缺点是采购和运维成本高。

3. 云 HSM / 云签名方案
这是现在更推荐的企业化方案。主流做法是把私钥放在云 HSM 或云签名服务中，CI/CD 通过受控服务发起签名请求。部分 CA 还支持 key attestation，也就是证明密钥确实在合规 HSM 内生成且不可导出。常见的有 AWS CloudHSM、Azure Dedicated HSM、Google Cloud HSM 这类受支持云 HSM；部分 CA 也提供 Key Attestation 的代码签名流程。

相关的架构设计：

推荐架构

• 证书层：购买 OV/EV Code Signing 证书

• 密钥层：私钥只在 HSM 内生成，不允许导出

• 签名层：部署签名服务，统一对外提供签名接口

• 流程层：接入审批、双人复核、日志审计、时间戳

• 集成层：CI/CD 只提交待签名文件，不接触私钥

典型流程

1. 在 HSM 内生成密钥对

2. 导出 CSR 提交给环度网信申请代码签名证书

3. CA 校验组织信息，并校验你的私钥保护方式或 attestation

4. 证书下发后绑定到 HSM 中的密钥

5. Jenkins/GitLab CI/GitHub Actions 调用签名服务

6. 对产物签名时同时加 RFC 3161 时间戳

7. 记录“谁在什么时间签了哪个版本”的审计日志

这类流程符合主流 CA 现在的签发和重签要求，比如代码签名证书在申请或重签发时，需要使用支持的硬件令牌或 HSM，并要求确认私钥保护符合规定。

落地时最关键的 6 个点

第一，密钥一定要“在 HSM 内生成”
不要先在 OpenSSL 里生成再导入，很多合规流程更偏好原生 HSM 生成，且 attestation 更容易做。

第二，签名机和构建机分离
CI/CD 不直接持有证书和私钥，只调用签名服务。这样泄露面最小。

第三，强制时间戳
否则证书过期后历史签名验证会很麻烦。

第四，做权限分层
开发者可发起签名，发布经理审批，安全管理员管 HSM 和证书，避免一个人全权操作。

第五，准备双证书或双 HSM 容灾
避免证书到期、HSM 故障、迁移窗口导致发版卡死。

第六，先确认 CA 是否接受你的 HSM 证明方式
不是所有 HSM、所有云厂商组合都被所有 CA 同样支持，尤其是是否支持 attestation、支持哪种接口，这一点要先和 CA 对齐。

怎么选方案

• 个人/小团队：USB Token 就够

• 有内网、合规、审计要求：本地 HSM

• 要自动化签名、跨区域团队、CI/CD 集成：云 HSM / 云签名最合适

常见接口兼容

• Windows：signtool + CSP/KSP/CNG

• Java：jarsigner + PKCS#11

• macOS/iOS：codesign，通常要结合 Apple 自己生态单独设计

• Linux 二进制或容器镜像：常配合自建签名服务、PKCS#11 或 Sigstore 类流程

最后，关于“代码签名证书 + HSM方案”，别停留在“买个 HSM”。更好的目标是做成一套 Code Signing Service：

• HSM 负责保管密钥

• 签名服务负责统一调用

• 审批系统负责授权

• CI/CD 负责发起请求

• 日志平台负责留痕审计

这样以后整个 Windows 驱动签名、Java 包签名、Docker 制品签名，体系都能复用。