从39个月到460天：代码签名证书有效期大缩水的应对策略
CA/B论坛CSC-31提案将代码签名证书有效期从39个月下调到460天，2026年3月1日生效。这不是孤立动作，而是整个PKI体系缩短有效期趋势的一部分。
缩短有效期的底层逻辑：一旦签名私钥泄露，攻击者可在证书未过期期间对恶意代码签名。39个月意味着最长近三年的风险暴露窗口。CRL和OCSP吊销机制可靠性不足，多数平台超时时fail-open放行。CSC-31把上限压到460天，是从源头压缩风险窗口，最坏情况暴露面收窄约61%。
CSC-31提案改了什么
2025年10月，CA/B论坛代码签名工作组通过CSC-31提案，将《代码签名基线要求》（CSCBR）从v3.9升至v3.10.0，核心变更一条：公开信任代码签名证书的最长有效期从39个月（约1185天）下调到460天（约15个月）。OV和EV证书均受此限制。
该变更适用于2026年3月1日及之后签发或续期的证书。此前签发的多年期证书维持有效至原定到期日，但此后任何重签发操作必须符合460天上限。提案由微软的Karina Sirota Goodley和Nate Santiago提出，Sectigo和eMudhra联合支持，投票结果7票赞成、0票反对、2票弃权，2025年11月17日正式纳入基线要求。
这不是孤立动作。同期TLS证书也在压缩——按SC-081v3，TLS证书有效期2026年3月降到200天，2027年100天，2029年47天。代码签名跟上了同一节奏。
时间戳：续期频繁后更关键的技术机制
证书有效期缩短后，RFC 3161时间戳从"锦上添花"变成技术刚需。
技术原理
时间戳遵循RFC 3161的TSP协议。签名时，签名工具计算已生成的PKCS#7签名值的哈希，发送给TSA（时间戳权威机构），TSA将哈希值和当前时间绑定后用自己的私钥签名返回，嵌入PKCS#7的unsignedAttrs字段作为counter-signature。
验证逻辑：
签名有效 = 证书notBefore < 签名时间戳时间 < 证书notAfter 且 签名时间戳时间 < TSA证书notAfter
关键点：系统检查的是签名那一刻证书是否有效，而非验证时的此刻。即使证书在2027年6月过期，只要签名时打了RFC 3161时间戳，2028年用户下载安装时签名依然有效。
没打时间戳的后果则相反——证书一过期签名即作废，触发"未知发布者"警告，Windows SmartScreen拦截，macOS Gatekeeper拒绝运行。39个月时代没打时间戳至少撑三年，460天后最多撑15个月。
各平台签名工具的时间戳参数
注意区分/tr（RFC 3161）和/t（旧版Authenticode时间戳），前者是推荐做法：
Windows（signtool.exe）：
signtool sign /fd SHA256 ^ /tr http://timestamp.digicert.com /td SHA256 ^ /sha1 <cert_thumbprint> ^ /d "Application Name" app.exe
Linux跨平台（osslsigncode，用-ts而非-t）：
osslsigncode sign -pkcs12 cert.pfx -pass "pwd" \ -ts http://timestamp.digicert.com \ -in app.exe -out app-signed.exe
macOS（codesign）：
codesign --timestamp \ --sign "Developer ID Application: Your Company (TEAMID)" app.app
密钥存储方案对比
CSCBR已要求EV代码签名证书私钥存储在FIPS 140-2 Level 3+或Common Criteria EAL 4+硬件中。有效期缩短让不同存储方案的管理成本差异放大。
| 维度 | USB令牌 | HSM | 云签名服务 |
|---|---|---|---|
| 私钥边界 | 硬件内 | 硬件内 | 云端HSM内 |
| 多机共享 | 否（需插拔） | 是（网络） | 是（API） |
| 物流依赖 | 是（续期需换令牌） | 否 | 否 |
| 续期成本 | 高（物流+停机风险） | 中（配置更新） | 低（密钥托管不变） |
| 合规适配 | FIPS 140-2 L3 | FIPS 140-2 L3+ | 视服务商 |
| 适用规模 | 单一团队 | 多产品线 | CI/CD重度依赖 |
关键点：云签名服务能自动化的是签名操作（API调用），不能自动化的是证书签发审批。代码签名证书申请续期仍需走CA的人工审核——企业身份验证、EV还需LEI等材料。所谓"云端"省的是密钥物流和管理开销，不是审批环节。
续期流程：为什么不能照搬TLS的ACME思路
TLS证书有ACME协议（RFC 8555），可以到期前自动申请、自动验证域名、自动签发部署。代码签名证书无法复制这套模式，原因在技术机制层面：
- 1. 私钥存储约束：CSCBR要求私钥在合规硬件内生成且不可导出，不能像TLS那样在软件层生成密钥对、提交CSR、接收签发证书。
- 2. 身份验证流程：TLS靠HTTP域名验证可自动化，代码签名需企业身份审核（EV还需验证法定代表人、实体地址），无法通过协议完成。
- 3. 审批周期：OV证书2-7天，EV证书1-2周，加令牌物流整个续期可能耗时2-4周。
务实做法不是追求全自动签发，而是把续期流程工程化：
- • 证书台账与到期监控：记录每张证书的序列号、CA、到期日期、使用场景、负责人。分级告警——到期前60天通知、30天升级、14天未启动续期报警。
- • 续期时间预算：预留至少4周窗口（CA审批1-2周、令牌物流3-7天、部署验证2-3天）。460天有效期意味着每13-14个月走一遍，纳入版本发布排期，避免证书到期撞关键发布。
- • 续期Runbook：标准化步骤——提交续期申请 → 完成身份重新验证 → 接收新证书 → 部署到各构建节点 → 测试签名验证 → 确认无依赖后吊销旧证书 → 更新CI/CD中的证书指纹引用。
CI/CD流水线中的签名集成
GitHub Actions + Azure Key Vault签名
jobs: build-and-sign: runs-on: windows-latest steps: - uses: actions/checkout@v4 - name: Build run: msbuild MyApp.sln /p:Configuration=Release - uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} - name: Sign run: | signtool sign /fd SHA256 \ /tr http://timestamp.digicert.com /td SHA256 \ /csp "Microsoft Software Key Storage Provider" /kv \ /kvm https://my-kv.vault.azure.net/codesign/my-cert \ /ktt <tenant_id> /kti <client_id> /kts <client_secret> \ bin/Release/MyApp.exe Jenkins + PKCS#11令牌
stage('Sign') { steps { sh ''' export PKCS11_MODULE=/usr/lib/pkcs11/opensc-pkcs11.so osslsigncode sign \ -pkcs11engine /usr/lib/engines-1.1/pkcs11.so \ -pkcs11module $PKCS11_MODULE \ -pkcs11cert "token_label:codesign" \ -key "slot_0-id_01" \ -ts http://timestamp.digicert.com \ -in build/app.exe -out build/app-signed.exe ''' }} 证书指纹解耦
常见的工程陷阱是把证书指纹硬编码到流水线配置里，续期后所有引用旧指纹的地方都得改。更好做法是变量化管理：
variables: CODESIGN_THUMBPRINT: ${{ vars.CODESIGN_THUMBPRINT_CURRENT }} 续期时只需更新一处变量，所有引用该变量的流水线自动使用新指纹，避免在多个pipeline文件里搜索替换。
迁移时间线
几个需要标记到日历的节点：
- • 2025年底：部分CA已停售2年期和3年期代码签名证书，囤多年期证书的窗口已关闭。
- • 2026年2月24日：此后签发或续期的证书一律受460天上限约束。
- • 2026年3月1日：CSC-31正式生效。此前签发的多年期证书维持有效至原到期日，但重签发必须符合新规。
如果当前证书在2026年3月1日后到期且有效期超过460天，该证书的到期日就是"最后一次享受旧规红利的节点"。到期后续期即落入460天框架，建议提前3-4个月启动续期评估。
往后看：后量子密码的迁移伏笔
460天不是终点。参照TLS证书的压缩轨迹，代码签名证书大概率继续缩短，推动力之一是密码学迁移。NIST于2024年8月发布首批后量子密码标准——FIPS 204（ML-DSA）和FIPS 205（SLH-DSA）都是签名算法，未来将逐步替代当前代码签名使用的RSA和ECDSA。
缩短有效期为算法迁移铺路：有效期越长，旧算法证书在生态中滞留越久，迁移阻力越大。对工程团队来说，这意味着签名工具链需要保持对算法升级的适配能力，关注signtool、codesign、osslsigncode的版本更新和后量子算法支持情况，是技术债管理的一部分。