时间戳机构（TSA）集成：工作原理与签署文档为何需要它

简短答案：什么是 TSA 集成

时间戳机构（TSA）集成，是把你的签署流程接入一个可信第三方，由它签发经过加密签名的证明，证实某个签名——或某段内容——在何时已经存在。TSA 全程看不到你的文档。你的系统在本地对内容计算哈希（通常是 SHA-256），只把这个哈希按 RFC 3161 协议发送出去，随后收到一枚签名的时间戳令牌，将哈希与可信的 UTC 时间绑定在一起。把令牌附加到签名上，你日后就能证明该内容在那一时刻已经存在，且此后未被改动。

签署流程为什么需要它？数字签名能证明是谁签的、内容是否完整，但"何时签"依赖的是你自己控制的本地时钟。TSA 令牌用一只可信、可审计的时钟替换了你的时钟。标准做法是在每次签名创建时加盖时间戳；对于存续期长的文档，还要嵌入验证数据和归档时间戳，让证据在多年之后仍可验证。

TSA 如何签发 RFC 3161 时间戳令牌

RFC 3161 刻意保持简单，它的四个步骤让每一个集成决策都变得清晰。

本地计算哈希。 客户端对需要时间绑定的数据计算摘要——在 PAdES/CAdES 流程中是签名值。文档始终不离开你的环境。
发送时间戳请求（TimeStampReq）。 哈希被封装进请求，可选携带策略 OID 和用于防重放的随机数（nonce）。
TSA 签名。 机构把哈希、来自其同步 UTC 时钟的时间、以及自身策略放入 TSTInfo 结构，再用它的 TSA 证书签名——这就是时间戳令牌（TimeStampToken）。
绑定令牌。 你的应用把令牌嵌入签名或归档数据中，验证时会对照哈希后的字节重新校验。

这些特性是结构性的：因为令牌包含你的原始哈希和 TSA 签名的时间，改动一个字节就会破坏匹配，质疑时间就等于质疑 TSA 经过审计的时钟。ETSI EN 319 421 和 422 定义了欧洲框架下的 TSA 策略与信任服务要求。

签署流程为何依赖可信时间戳

三种失效模式解释了为什么高风险流程必须做 TSA 集成。

不可抵赖性。 对合同提出异议的签署人可能声称密钥被盗用，或者时钟不准。TSA 令牌能同时化解这两种说法：它由无利害关系的第三方针对确切的签署内容哈希签发，其时钟可追溯至 UTC。

争议证据。 合同往往取决于先后顺序——要约在撤回前被接受，保密协议在泄露前签署。我们的 DocuSign 完成证书与审计轨迹指南说明了平台证据记录包含什么，以及加密时间戳相比日志记录多出了什么。

长期验证（LTV）。 这是大多数团队集成 TSA 的根本原因。签名证书会过期——通常在一到三年内——如果没有额外证据，一份十年前的合同在证书失效当天就变得无法验证。PAdES、CAdES、XAdES 通过逐级方式解决这个问题：B-LT 把验证材料（证书和吊销数据）嵌入文档，B-LTA 再加周期性的归档时间戳，让整套证据在可信时间中重新锚定数十年。在 eIDAS 框架下，合格时间戳支撑最高保障级别的 QES 和 AdES 验证链；我们的英国 QES 证书成本指南展示了合格保障级别如何影响定价。

TSA 时间戳的三种集成模式

集成模式有三种，选错模式是最常见的规划失误。

模式一：平台托管时间戳。 电子签名平台在签署过程中自动请求并嵌入时间戳，每份完成的签署文件都自带可信时间，无需写代码。你的工作转为尽职调查：加盖的是哪种时间戳（签名值、文档，还是两者）、是否嵌入 LTV 数据、以及离开平台后证据如何存续。了解证书机构列表中该关注什么会有帮助，因为 TSA 证书来自同一套信任基础设施。

模式二：通过 API 或 SDK 在应用层集成。 你的应用直接调用 TSA：对签名或文档计算哈希，提交 RFC 3161 请求，接收令牌，并将其嵌入签名结构——签名时间戳和验证数据时间戳是 PAdES 中的标准挂载点。这适合自建签署服务、以及时间戳必须在精确时刻触发的流程，代价是你要自己负责重试、时钟偏差处理和令牌存储。

模式三：归档与证据系统。 归档系统批量处理已签署文档：嵌入验证数据（B-LT），并按计划重新加盖时间戳（B-LTA）。这适合留存制度、知识产权证据和受监管归档——还能为存量旧文档补强的证据。

选择 TSA 时的核查项

把 TSA 选型当作信任决策：要验证，不要想当然。

策略 OID 与合规。 每枚令牌都携带策略标识符；确认它符合你的要求，并确认提供商公开了其对照 ETSI EN 319 421/422 的合规状况。
证书链与根信任。 TSA 的证书必须链到你的验证方信任的根，且密钥用途正确。其生命周期问题与我们关于如何制作数字签名证书的指南相通。
时钟同步。 TSA 的时间必须通过冗余、受监控的时间源追溯至 UTC，且方法有据可查。
可用性与冗余。 TSA 宕机会让模式一和模式二停摆。询问可用率、故障切换和备用 TSA 支持情况。
可审计性。 你要的是法庭可以核验的公开审计报告，而不仅仅是你自己的日志。

你的流程何时真正需要 TSA 集成

先用这张表框定工作范围。

场景	是否需要 TSA 集成	需要什么
受监管或需公证的协议（金融、政务、合格电子签名）	实践中必需	合格时间戳、嵌入 LTV、可导出证据
知识产权与法律证据（优先权或存在日期）	强烈建议	创建时对内容哈希加盖时间戳、B-LTA 归档重盖
eIDAS 类框架下的跨境交易	最高保障级别必需	合格 TSA、策略 OID 对齐目标框架
长留存期（7–10 年以上），无论争议风险高低	建议	至少 B-LT；按计划做 B-LTA 重盖时间戳
争议价值低的日常商业合同	可选	如平台提供则用平台时间戳；记录权衡取舍

触发因素不是签署量，而是时间：签名需要保持可证明的期限越长，TSA 就越不可或缺。

验证时间戳令牌与常见陷阱

验证是集成悄悄出问题的地方。四项检查必不可少。

令牌完整性。 重新计算时间绑定数据的哈希，与令牌中的哈希比对，然后用 TSA 的证书链验证 TSA 签名。
信任与策略。 确认证书链抵达可信根，且策略 OID 可接受。
时间合理性。 把令牌时间对照 TSA 证书的有效期窗口和你的时钟偏差边界检查。
LTV 完整性。 确认文档嵌入了 TSA 证书和吊销数据，否则时间戳会随 TSA 证书到期而失效。具体操作可参见如何在 PDF 中验证签名。

反复出现的陷阱包括：

以为时间戳比 TSA 证书活得久。 没有嵌入验证数据和归档重盖，时间戳在证书到期时即不可验证——LTV 才是解法。
忽略时钟偏差。 把每枚超出本地时间几秒的令牌都判为无效，会制造大量误报。
哈希算法太弱。 坚持 SHA-256 或更强。
多枚时间戳、顺序不清。 一份 PAdES 文档会累积多枚时间戳；验证必须尊重其先后次序，否则 LTV 链断裂。
信错了锚。 来自你的验证方不信任的 TSA 的令牌看似有效，到了法庭就失效——这正是我们在自签名证书用于商业合同的安全性分析中剖析的信任失效。

集成前技术核查清单

在写代码或签供应商合同之前，先过一遍这份清单。

明确你要时间绑定的对象：签名值、完整文档，还是验证数据包。
选定模式（平台、API 或归档），并确认它与你的签名格式（PAdES、CAdES 或 XAdES）匹配。
核实 TSA 的策略 OID、证书链、根信任和公开审计。
确认哈希与签名算法（至少 SHA-256）。
明确 LTV 目标：签署时达到 B-LT，并制定 B-LTA 重盖时间戳计划。
规划失败路径：TSA 宕机、重试、备用 TSA、签署人体验。
上线前用独立验证器测试——包括用一枚证书已过期的时间戳做测试。

时间戳背书的签署证据：Nota Sign

Nota Sign 是 FaDaDa 的全球化电子签名平台，IDC 连续多年将其评为中国电子签名软件市场第一。在合规深度上，Nota Sign 提供完整的能力组合：支持 SES/AES/QES 三个签名级别，覆盖从标准电子签名到合格电子签名的全梯度；在亚太区接入 iAM Smart 与 Singpass 等国家数字身份体系；以区域数据中心满足数据驻留要求；法律效力覆盖 100 多个国家和地区。平台不设 per-seat（人均/席位）费用，中大型客户可按签署量申请定制方案。

如果你正在评估时间戳与证据能力，欢迎与我们的团队沟通，获得一次贴合你需求的演示。