数字签名证明一份文件由某个特定证书持有人、在某个特定时刻签署——但前提是底层证书及周边证据仍然可验证。证书会过期。吊销清单会被精简。信任锚会更换。今天验证完美无误的签名,五年后可能变得无法验证——除非有人采取了保护其长期有效性的步骤。
这组步骤在标准世界里有自己的名字:长期有效性验证(Long-Term Validation,LTV)。这篇指南解释签名为什么会随时间失效、时间戳与吊销证据如何解决问题、"符合 LTV"在实践中到底意味着什么,以及在你把需要保存多年的记录托付给电子签名供应商之前,应该问它哪些问题。
为什么一个有效的签名会随时间失效
把数字签名想象成一条由三重承诺构成的链条:签署人的证书证明谁签的,时间戳证明何时签的,吊销信息证明证书在那个时刻仍然有效。每一重承诺都有保质期:
- 证书会过期。 签署证书通常存活一到三年。过期之后,如果证据没有随文件一起存档,天真的验证器无从知道证书在签署当时是否有效。
- 吊销清单会消失。 证书颁发机构按计划发布吊销信息(CRL 与 OCSP 响应)。如果签名依赖检查一份不再发布的 CRL,检查就会失败——尽管签名创建时完全有效。
- 信任锚会更换。 根 CA 与中间 CA 会随时间被新增、轮换和退役。2031 年的验证器可能不再信任签发 2026 年证书的那个根。
- 哈希与密钥强度的假设会老化。 标准机构会提高最小密钥长度并转向更强的哈希算法,这可能让旧签名在未来工具中落在支持参数之外。
这些都不是原签名本身的缺陷。它们是时间的属性——而它们正是 LTV 存在要消除的东西。
长期有效性验证实际上做什么
LTV 的核心思想是,在签署当时把未来验证器需要的证据一并存档,让签名不依赖"今天的基础设施明天仍然存在"。被广泛记录的构件包括:
- 时间戳(RFC 3161)。 受信任的时间戳机构对"某个文档哈希在某个特定时刻存在"签署一份声明。因为时间戳本身就是一个新的数字签名,它确立签署发生的时间,而不依赖签署人自己的证书持续有效。
- 吊销证据采集。 签署人的软件抓取证明证书在签署时有效的 CRL 或 OCSP 响应,并将其与签名一同保存。未来的验证器读取存档证据,而不是去问一个可能不再回应的 CA。
- 签名存档格式。 PAdES(PDF 高级电子签名)等标准定义了如何把签名、时间戳和吊销证据嵌入 PDF 本身,使文档自包含。把这些要素分开存放的存档方式有丢失关联的风险。
- 周期性重新验证。 对超长保存期,一些工作流按计划对存档文档重新签名或刷新,让每个周期用新时间戳重启有效性窗口。
产出是一份自带证明的签署文档:任何使用合规验证器的人都能确认签名截至签署时间的有效性,而不需要 CA、签署人或原始基础设施可被触达。
为什么"今天有效"和"十年有效"是两个不同的购买问题
大多数电子签名产品谈论的是签署那一刻:审计轨迹、完成证书、身份验证。这些很重要,但它们不等于长期有效性。问题会急剧分岔:
如果你保存签署文档是为了内部记录,左列就够了。如果你要保存多年合同、证书或合规记录——尤其是你在数字签名标准被正式化的司法辖区签署,例如 eIDAS 下的 SES/AES/QES 等级——右列才是重要的。我们的数字签名如何在真实业务工作流中运作指南覆盖了基础机制,面向全球团队的 eIDAS 合规指南则解释正式效力等级从哪里介入。
如何检查你的签署工作流是否保留 LTV
不用成为 PKI 专家也能按 LTV 要求审计一套签署配置。过一遍这份清单:
- 工具是否在签署时嵌入时间戳? 索取验证报告,或测试一个签名,查找 RFC 3161 时间戳块。
- 吊销检查是"存档"还是仅仅"执行过"? 产品在签署时检查 CRL/OCSP 但随后丢弃响应,并没有为将来保留证据。
- 签署导出用什么格式? PDF 导出应携带签名、时间戳和吊销证据(PAdES 风格)。如果"导出"给你的是一份没有嵌入证据的平面 PDF,那就不是 LTV。
- 全新验证器能否离线验证旧文件? 下载一份两年前的签署文件——如果当前工具无需联系原 CA 就能验证它,这是一个很强的信号。
- 长保存期是否有重新验证策略? 问清楚多年期存档会发生什么:定期刷新、重新打时间戳,还是原样存储。
- 证书链是否保持可解析? 检查工具是否存档中间证书,而不仅仅存档签署人的叶子证书。我们的证书颁发机构清单入门解释了为什么链的可解析性很重要。
- 自签名证书是否被排除? 自签名证书没有外部信任链,通常无法提供耐久的第三方验证。我们的自签名证书用于商业合同是否安全分析详细解释了其中的风险。
会悄悄破坏长期有效性的常见错误
即使团队买了能力够强的产品,也会在运营中把 LTV 弄坏:
- 从错误的管道导出。 如果签署的 PDF 在存档前被重新保存、压平或转换,嵌入的签名证据可能被剥离,尽管文件"看起来一样"。
- 只保存完成证书。 供应商的证书是对工作流的一份摘要;它不是签名本身的密码学证据。请存档真正的签署文件。
- 把截图当证据。 一张签署页的截图在密码学上证明不了任何东西。签名必须活在文件内部。
- 假设供应商会永久存档。 "我们账户里有"是服务承诺,不是格式保证。核实供应商的导出是否保留 LTV 要素,并规划你自己的存档副本。
- 无视格式更替。 如果你的长期存档将来要被新系统读取,优先选择面向存档的格式(PDF/A 类),让渲染与证据在工具更替中存活。
想看实践中正当的验证长什么样,我们的在 PDF 中验证签名和核实 DocuSign 签名的证据指南会带你过一遍验证报告及每个字段的含义。
关于长期有效性,该向你的电子签名供应商问什么
在把比当前工具寿命更长的文档托付出去之前,把这些问题落到书面:
- 产品是否默认在签署的 PDF 中嵌入 RFC 3161 时间戳?
- CRL/OCSP 响应是与签署文件一同存档,还是只在签署时检查?
- 导出的存档格式是什么,它是否携带完整的证据链?
- 产品能否按计划为长期保存重新打时间戳或刷新签名?
- 支持哪些签名等级与标准(例如 eIDAS 下的 SES/AES/QES)?
- 如果你停止订阅,有效性证据会怎样?
用 Nota Sign 让签署记录多年可验证
如果你正在为一个需要多年有效的记录选择签署平台,签名等级支持是要先确认的第一件事。Nota Sign 是法大大旗下的全球电子签名平台,支持由区域数据中心支撑的 SES、AES、QES 三级签名——长期有效性依赖的正是这些签名等级——并且连续多年被 IDC 评为中国市场电子签名软件市场份额第一,法律效力覆盖 100 多个国家和地区。
对长保存期要求的团队,实际问题通常是签名等级支持与成本结构。Nota Sign 不按席位收费,对偶发发送者较多的团队同样经济,而不只是高频使用者;中大型企业则可按体量与合规需求定制方案。APAC 合规深度——香港 iAM Smart、新加坡 Singpass——为跨境记录补齐了最后一块拼图。如果你想了解 Nota Sign 的签署与存档选项如何匹配你的保存期要求,我们的团队可以带你过一遍。









