2026年8月6日
引言
为 PDF 添加基于证书的数字签名之前，先确认收件人对签署方式和证书的要求。冻结最终版 PDF，按照获批流程使用指定证书和私钥完成签署，按要求保存已签署文件，再由另一名审核人员依据收件人的检查清单，核对文件完整性、证书信任、签署时间、吊销信息、签署人详情以及允许的变更。
这个流程不只是放上一张签名图片或输入姓名。电子签名泛指以电子方式表达同意或签署意愿的行为。数字签名通过密码技术支持签署人身份认证和文件变更检测；基于证书的签署流程还可按照证书颁发机构和收件人的适用政策提供身份信息。仅看页面上的签名外观，无法回答收件人的验证问题。
美国国家标准与技术研究院《数字签名标准》说明，数字签名可用于检测数据是否遭到未授权修改，并验证签署人身份。该标准规定了获批的签名算法，但不会替收件人决定接受哪种证书、PDF 配置文件、时间戳、信任锚或文件变更规则。这些都由依赖方决定。
因此，本文将签署和接受判定分开处理。以下内容是操作指引，不构成法律效力判断。文件负责人、收件人、证书政策和适用要求才是判断依据。
确认 PDF 是否需要基于证书的数字签名
先看收件人的要求，不要先点软件按钮。不同签署应用的术语和可选方式并不相同。应从收件人的说明中确认所需方式，不要只凭界面标签或签名外观判断。
准备 PDF 前，先完成以下方式确认：
- 收件人要求：询问接收方的具体要求。记录文件类型、提交渠道、适用政策，以及异常情况由谁答复。
- 所需签名类型：确认普通电子签名是否足够，还是必须采用基于证书的 PDF 数字签名。不要仅凭“在此签名”几个字作出判断。
- 证书政策：询问收件人指定的证书颁发机构、证书类型、签署人身份要求、算法和密钥管理条件。政策没有说明时，应升级处理，不要自行补充规则。
- 签署人保障：确认流程需要哪些身份和签署身份凭证。业务授权应单独审批，不能假定证书结果已经解决授权问题。
- 文件变更规则：询问收件人是否允许签署后修改文件；如果允许，可接受哪些变更，以及获批流程指定了哪项设置。不要自行采用默认规则。
- 验证方式：记录获批的验证应用，以及审核人员需要核对的信任、时间、吊销信息、签署人详情、文件变更和留存证据。判定标准应来自收件人的政策。
这些问题要在文件交给签署人之前解决。否则，收件人可能拒绝接收结果，或要求更正文件后重新签署。
同时确认 PDF 已准备妥当。文件应页面齐全、内容清晰、顺序正确，并已获批。批注、遮盖内容、附件或动态内容应按文件负责人的发布流程处理。只有控制流程要求时，才记录固定文件名、版本和文件哈希。签署流程开始后，不要悄悄替换获批源文件。
为最终 PDF 添加数字签名
不同 PDF 应用的标签、界面和技术配置可能不同。以下步骤是控制清单，不是所有产品通用的操作说明。请按照当前获批签署应用、证书提供方和收件人政策的说明操作。
- 打开获批的最终版 PDF。核对文件名、版本、页数，以及发布流程要求的其他标识。只签署受控副本。
- 选择获批的签署方式。使用应用说明和收件人政策指定的功能。如果流程要求基于证书签署，不要改用手绘、图片或输入文字的签名方式。
- 选择获批证书。确认凭证在流程指定或允许的范围内。只有流程要求时才记录证书字段；如果无法辨认所需凭证，应停止操作。
- 放置签名字段。使用获批位置，不要遮挡文件文字。字段位置和显示样式只属于呈现方式，不能代替收件人的接受判定。
- 设置显示样式。只加入本文件获批的显示信息。审核人员仍应查看规定的验证报告，不能依赖印章图片、扫描签名或“已数字签名”标签。
- 应用规定的变更设置。只使用文件负责人和收件人指定的设置。如果流程没有说明允许哪些后续变更，应在签署前升级处理。
- 通过获批的私钥流程完成签署。私钥必须始终处于组织和证书提供方批准的保管与密钥管理流程中。不得共享或通过邮件发送私钥，也不得把私钥、个人识别码或恢复密钥放入事项记录。任何导出或备份都必须获得明确授权，并按照适用政策和提供方流程妥善保护。如果怀疑私钥泄露，应停止操作，并执行获批的事件处理和证书状态处置流程。
- 按说明保存已签署文件。按照流程指定的格式和位置留存电子文件。如果还需要打印件或扫描件，应将其标明为衍生版本，并保留规定的电子记录。仅在获批记录有要求时，才记录文件名、版本、哈希、签署人、证书标识和事件时间。
美国国家标准与技术研究院的标准支持数字签名用于签署人身份认证和文件变更检测的一般用途。本文不规定 PDF 签名的内部格式、证书路径算法、时间戳语义或吊销流程。这些细节应以签署应用和证书提供方的最新说明为准。
不要覆盖未签署的获批源文件。源文件、已签署文件和验证记录应分开保存，便于审核人员追溯哪份文件获批、哪份文件完成签署，以及最终接受的是哪份文件。
验证证书状态与文件完整性
使用获批验证应用，对留存的已签署 PDF 执行收件人的验证清单。仅看到签名图片，不能完成这项检查。应如实记录应用报告的结果；如果某项状态不在收件人政策规定的接受范围内，应升级处理。
检查文件完整性
如实记录应用报告的完整性结果。如果收件人的清单还要求查看已签署版本、后续变更或允许的变更设置，也应记录相应字段，但不要自行解释其含义。只应用收件人政策明确规定的接受规则；政策未说明时，应升级处理。
记录政策要求的证书路径结果
如果收件人的流程要求查看证书路径或信任链，应记录获批应用报告的结果，并与该流程指定的信任配置进行比较。不要把本地显示的成功状态当成所有接收方都会接受的结论。
只记录收件人清单要求的证书、应用和信任环境字段。如果结果未知、不完整、不匹配或无法识别，应按照政策规定的异常流程处理，不要根据本文自行诊断。
记录要求的有效期与时间字段
收件人政策有要求时，记录获批应用显示的证书日期，以及时间或时间戳结果。应采用政策指定的判定规则，不要依据本文自行判断这些信息的证据效力。
如果日期或时间结果触发异常，应保留应用报告的状态并升级处理。本文不提供历史有效期或长期验证的判断规则。
检查吊销信息
如果收件人的政策要求检查吊销信息，应记录获批应用或提供方流程报告的状态和获取结果。结果不可用、过期、未知或不在政策规定值内时，应按异常规则处理，不要把无法识别的结果记为通过。
核对签署人及签署身份
仅按获批流程要求，将显示的签署人信息与预期签署人进行核对。文件负责人有要求时，另行记录业务授权或签署身份。如果信息不一致，应升级处理，不要根据证书字段推断授权关系。
在接受前验证基于证书的 PDF 数字签名
使用统一的接受检查表，让每名审核人员回答相同问题。不能只看“状态图标为绿色”就作出决定。审核人员要判断现有证据是否符合收件人的指定政策。
将结果填入 PDF 证书签署与依赖方验证记录。记录内容应与收件人的检查清单一致。下列是可选字段，不是所有场景都必须采用：
- 事项标识、文件名、版本、已签署文件哈希和审核日期；
- 签署人姓名与签署身份、证书主题、颁发者、标识和有效期；
- 验证应用报告的签名算法，以及指定的接受政策；
- 验证工具和版本、信任锚、信任链结果及完整性结果；
- 声明的签署时间、适用时的时间戳结果和吊销状态证据；
- 允许的变更设置、观察到的签署后变更和接受决定；
- 审核人员、异常负责人、升级原因，以及更正后重新签署的处理记录。
只使用收件人或文件负责人定义的决定值，例如“接受”“拒绝”或“升级处理，证据不足”。缺失或无法识别的检查项不能记为通过。如果两个获批环境报告的结果不同，应保留两份结果，并执行指定的异常处理流程。
把已验证 PDF 关联到 Nota Sign 签约记录
验证结果应与参与方签署流程保持关联，不要只留在审核人员的下载文件夹中。获批源文件、已签署 PDF、证书验证记录、异常处理历史、已完成协议和审计记录应使用同一个事项标识。
Nota Sign 数字签名流程的公开说明涵盖基于证书的签署、身份验证、完整性检查和审计记录。具体可用范围可能取决于国家或地区、信任服务提供方和文件类型。正式使用前，应确认目标市场所需的签署方式。
请明确区分两层证据：
- 签署平台证据：获批流程实际记录的参与方身份认证、文件事件、时间戳、证书详情和审计活动。
- 依赖方验证证据：获批应用针对各项政策问题输出的结果、适用政策依据，以及审核人员记录的决定。
把两层证据关联起来，并不表示签署平台代替收件人作出接受决定。审核人员仍要执行指定政策。如果涉及外部签署的 PDF，在对外表述相关产品能力之前，应确认获批的 Nota Sign 流程是否支持预期的文件接收和留存方式。
验证记录可能包含证书标识、签署人详情、网络结果和业务背景，应按组织政策限制访问。不得把私钥、个人识别码、恢复密钥或身份认证密钥放入记录。任何已获授权的私钥备份或导出只能在批准的密钥管理流程中处理，不能放入协议事项文件。
最终建议
可靠的 PDF 数字签名流程包含两个责任节点：签署人按照获批的证书和私钥流程签署冻结文件；审核人员完成收件人指定的验证清单。两部分所需证据应使用同一个事项标识留存。如果必需的信任、时间、吊销、身份、变更或完整性结果缺失或无法识别，应升级处理，不要把签名外观当成证明。
验证一份已签署 PDF，并将验证结果关联到相应的 Nota Sign 事项记录。如果团队正在评估特定市场的证书型签署路径，可联系 Nota Sign，讨论目标市场配置，以及复核人员需要的签署、审计和依赖方证据。
