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和NateSantiago提出，Sectigo和eMudhra联合支持，投票结果7票赞成、0票反对、2票弃权，2025年11月17日正式纳入基线要求。
这不是孤立动作。同期TLS证书也在压缩——按SC-081v3，TLS证书有效期2026年3月降到200天，2027年100天，2029年47天。代码签名跟上了同一节奏。
缩短有效期的底层逻辑：一旦签名私钥泄露，攻击者可在证书未过期期间对恶意代码签名，系统会判定为“可信”。39个月意味着最长近三年的风险暴露窗口。CRL和OCSP吊销机制在实际部署中可靠性不足，多数平台超时时fail-open放行。CSC-31把上限压到460天，是从源头压缩风险窗口，最坏情况暴露面收窄约61%。
时间戳：续期频繁后更关键的技术机制
证书有效期缩短后，RFC3161时间戳从“锦上添花”变成技术刚需。
技术原理
时间戳遵循RFC3161的TSP协议。签名时，签名工具计算已生成的PKCS#7签名值的哈希，发送给TSA（时间戳权威机构），TSA将哈希值和当前时间绑定后用自己的私钥签名返回，嵌入PKCS#7的unsignedAttrs字段作为counter-signature。
验证逻辑：
签名有效 = 证书notBefore < 签名时间戳时间 < 证书notAfter
且 签名时间戳时间 <TSA证书notAfter
关键点：系统检查的是签名那一刻证书是否有效，而非验证时的此刻。即使证书在2027年6月过期，只要签名时打了RFC3161时间戳，2028年用户下载安装时签名依然有效。
没打时间戳的后果则相反——证书一过期签名即作废，触发“未知发布者”警告，WindowsSmartScreen拦截，macOS Gatekeeper拒绝运行。39个月时代没打时间戳至少撑三年，460天后最多撑15个月。
各平台签名工具的时间戳参数
注意区分/tr（RFC 3161）和/t（旧版Authenticode时间戳），前者是推荐做法：
Windows（signtool.exe）
signtoolsign /fd SHA256 ^
/tr http://timestamp.digicert.com /td SHA256^
/sha1 <cert_thumbprint> ^
/d "Application Name" app.exe
Linux跨平台（osslsigncode，用-ts而非-t）
osslsigncodesign -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: YourCompany (TEAMID)" app.app
密钥存储方案对比
CSCBR已要求EV代码签名证书私钥存储在FIPS 140-2 Level 3+或CommonCriteria 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），可以到期前自动申请、自动验证域名、自动签发部署。具体可以访问www.globalsign.cn咨询在线客服。代码签名证书无法复制这套模式，原因在技术机制层面：
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 KeyStorage Provider" /kv \
/kvmhttps://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 '''
exportPKCS11_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" \
-tshttp://timestamp.digicert.com \
-in build/app.exe -outbuild/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的版本更新和后量子算法支持情况，是技术债管理的一部分。