2024年签的名，2026年证书过期了，驱动为什么还能正常加载？

对软件开发者来说，代码签名并不陌生：它能证明软件来源可信、内容未被篡改。但不少开发者在签名时会忽略一个不起眼的选项——时间戳。事实上，时间戳直接决定了签名能否在证书过期后继续有效，也是主流操作系统和应用商店审核的硬性要求。本文从原理、验证逻辑和实操三个层面，说清楚代码签名为什么必须加时间戳。

代码签名时间戳是什么

代码签名基于PKI公钥基础设施：开发者用私钥对代码哈希值加密生成签名，操作系统用公钥验证软件的来源与完整性。而时间戳是由权威时间戳服务器（TSA）签发的一份”时间证明”，它把代码哈希值与可信的UTC时间绑定后，再用服务器私钥签名，生成时间戳令牌嵌入签名中。

需要强调的是，这个时间不是本地系统时间。本地时间可以随意修改，不具备公信力；只有符合RFC 3161标准的权威时间戳服务器给出的时间，才被操作系统和浏览器信任。这也是时间戳能作为”签名时间证据”的根本前提。

证书有效期短，软件生命周期长

用于代码签名的数字证书有效期通常只有1到3年。出于密钥安全和身份审核的考虑，证书不能无限续期。但软件的实际生命周期往往远超证书有效期：工具软件、驱动程序、工业控制软件服役五到十年十分常见。

如果没有时间戳，证书一到期，所有已分发软件的签名会随之失效。用户安装或运行时会遇到”未知发布者”警告，甚至被系统直接拦截，开发者只能重新签名、重新发布，存量用户的信任成本可想而知。时间戳正是为了解决这对矛盾而存在。

时间戳如何影响签名验证逻辑

操作系统验证代码签名时，通常遵循三步：校验证书链是否受信任、验证签名是否在证书有效期内生成、比对代码哈希值是否一致。有与没有时间戳，第二步的判定结果完全不同。

没有时间戳，系统只能以”当前时刻”为准——证书现在过期，签名就判无效。有了时间戳，系统可以确认”签名发生在证书有效期内”，即使证书后来过期甚至被吊销，签名依然有效。举个典型例子：2024年用一张2026年到期的证书为驱动签名并加盖时间戳，到了2027年证书早已过期，但系统通过时间戳确认签名行为发生在有效期内，驱动依然可以正常加载。

证书被吊销时，时间戳同样关键

除了正常过期，证书还可能因私钥泄露、企业信息变更或违规使用被CA提前吊销。没有时间戳的签名会随证书吊销立即失效，所有已发出的软件瞬间失去信任背书，用户端大面积报错，售后与技术支持压力陡增。

而带有可信时间戳的签名，只要签名时间早于吊销时间，就可以继续通过验证。对长期分发、持续迭代的软件产品来说，这相当于给历史版本上了一道保险，避免因证书状态意外变化波及全部存量用户。

平台与合规要求：时间戳不是可选项

从行业规范看，CA/Browser Forum的代码签名基线要求已将时间戳纳入最佳实践；国内《网络安全法》《个人信息保护法》对软件完整性与可信性也提出了更高要求，代码签名的可信验证离不开时间戳支撑。

从平台执行看，Windows对驱动签名验证严格，缺少有效签名与时间戳的驱动无法加载；各应用商店的审核机制同样会核查签名状态。换句话说，时间戳已经不是”加分项”，而是软件能否正常分发的基础门槛。

如何正确为代码签名加时间戳

操作层面并不复杂。以Windows的signtool为例，签名命令中通过 /tr 参数指定符合RFC 3161的时间戳服务器地址，即可在签名的同时自动完成盖戳；使用证书厂商提供的签名工具或云签名服务时，时间戳通常已默认启用。

需要注意两点：一是确保签名时网络可以连通时间戳服务器，盖戳失败应及时重试或更换服务器；二是选择受信任CA提供的时间戳服务，避免使用来源不明的服务器，否则时间戳本身可能不被系统认可。花几分钟做好这一步，就能省去证书更新后重新签名、重新分发的全部麻烦。

沃通CA提供全球信任的EV代码签名证书、OV代码签名证书产品，基于丰富的行业经验和本土的服务优势，提供专业售前服务和一对一技术指导，能够帮助用户高效解决证书选型、证书申请、证书签发、证书Ukey邮寄及软件代码签名等各类应用问题，帮助开发者更加高效地完成证书申请、软件签名及发布。