为什么数字签名很重要

数字签名已成为电子交易的法律支柱。无论是合同、发票还是监管申报，签名都将签署人与内容绑定，并提供不可否认性、完整性和时间戳证据。法院和合规审计员越来越将正确签名的 PDF 或 XML 文档视同纸质文件上的手写签名。正因如此，丢失签名或在未重新签署的情况下修改已签数据，都可能导致整份文档失效，让组织面临法律风险，并迫使进行代价高昂的重工。金融、医疗和政府等行业的风险尤为高，因为这些领域对电子记录的信任是强制性的。

转换如何破坏签名

文件转换很少是中性操作。当包含嵌入式 PKCS#7 签名的 PDF 被平面化为图像时，密码学封印会消失。一些转换工具会剥离 XML‑DSig 元素、删除证书引用或重写文件的字节结构，导致签名保护的哈希值改变。即使是看似无害的操作——比如重新压缩图像、修改换行符或更改 PDF 版本——如果工具未保留已签字节范围，也会使签名失效。结果是文档外观与原件相同，却无法通过验证检查。

可能遇到的数字签名类型

了解签名格式有助于选择合适的转换方法。

  • PDF 签名 – 嵌入在 PDF 目录中，覆盖定义好的字节范围。PDF/A‑3 与 PDF/E 可以保留签名，而 PDF/A‑1 会将其剥除。
  • XML 数字签名 (XML‑DSig) – 用于电子发票（PEPPOL）、电子采购以及众多政府表单。必须保持 <Signature> 元素完整，任何空白字符的变化都可能使哈希失效。
  • CMS/PKCS#7 容器 – 常作为 Office Open XML 文件（.docx、.xlsx）中的独立 Signature 部分附加。只要保持部件层级不变，容器可在格式更改时存活。
  • 分离签名 – 单独的文件（例如 .p7s），引用原始文档。若转换过程中对原文件重命名或移动，链接会断裂，除非同步更新签名文件。

转换前检查清单

在开始批量或单文件转换之前，请按以下步骤操作：

  1. 识别签名类型 – 使用能够显示签名详情的查看器（Adobe Acrobat、XMLSec 或 OpenSSL）。记录哈希算法、签名证书以及签名范围（整个文档还是选定字段）。
  2. 确认签名有效性 – 验证签名当前是否有效。转换前已经损坏的签名不会在事后 magically 恢复。
  3. 确定目标格式 – 并非所有格式都能承载签名。如果目标不支持签名，考虑为归档保留原始签名格式的副本。
  4. 创建只读备份 – 将已签文件复制到安全位置。这能在转换期间防止意外数据丢失。

选择友好签名的目标格式

当转换不可避免时，选用明确支持该签名类型的格式。

  • PDF → PDF/A‑3 – PDF/A‑3 允许嵌入任何文件，包括签名容器，同时保持视觉保真度。
  • DOCX → DOCX – 将 Word 文档重新导出到相同的 OOXML 容器，只要转换引擎不重写 Signature 部分，就能保留 CMS 签名。
  • XML → XML – 使用能够识别 XSLT 且不重新格式化空白的转换工具。保留原始 XML 声明和命名空间前缀。
  • 基于图像的扫描 → PDF（含签名层） – 若原始文档的数字印章以扫描图像形式签署，将图像嵌入包含原始签名注释的 PDF，而不是将其平面化。

保持签名的转换工作流

下面给出一个实用的逐步工作流，可手动执行或通过脚本自动化。

  1. 提取签名（可选） – 对于无法携带签名的格式，可使用 openssl cms -verify -inform DER -in sig.p7s -noout 等工具提取 CMS/PKCS#7 二进制块，并另存为独立文件。
  2. 转换核心内容 – 使用提供“保留元数据”标记的转换引擎。许多云服务通过 API 参数暴露此功能；例如使用 convertise.app 时，可勾选 “keep original signatures”。
  3. 重新嵌入签名 – 若目标格式支持嵌入，则将签名块放回相应容器（如向 XML 文档添加 <Signature> 元素，或将 CMS 部分放入 DOCX 的 zip 包中）。
  4. 重新计算已签字节范围 – 对于 PDF 签名，字节范围定义在 /ByteRange 数组中。重新嵌入后，更新该数组以反映新增对象。iText 7、PDFBox 等库提供在不破坏密码学封印的前提下重建签名字典的 API。
  5. 验证结果 – 在受信任的查看器中打开转换后的文件并执行验证检查。PDF 使用 Acrobat 时若签名完整会显示绿色勾；XML 可使用 xmllint --verify 并配合相应的模式和签名文件。
  6. 记录最终文件哈希 – 将转换后文档的 SHA‑256 哈希写入防篡改日志，这为审计提供了签名在转换后仍被保留的凭证。

云转换与隐私顾虑

将转换任务交给 SaaS 平台意味着便利与控制的权衡。一个以隐私为中心、在内存中完整处理文件并在会话结束后删除文件的服务能降低泄露风险，但仍需确认该服务不会在清理流程中剥离签名。审查供应商的隐私政策，索取数据处理协议，并在可能的情况下，用非敏感的已签文件进行试验转换，以验证签名是否存活。

转换后验证签名

转换看似成功，却可能在背后悄悄破坏签名。系统化的验证可以降低此类风险：

  • 自动化批量验证 – 使用 pdfsig（Poppler）验证 PDF，使用 xmlsec1 验证 XML，或使用 openssl cms 验证 CMS 文件的脚本，可遍历文件夹并生成通过/未通过报告。
  • 目视确认 – 在原签名应用中打开部分转换后的文件，检查签名面板、签署人姓名以及时间戳。
  • 证书撤销检查 – 确认用于签名的证书仍然有效且未被撤销。某些转换服务可能会剥离 CRL 或 OCSP 信息，需要自行重新附加。

常见陷阱及规避方法

陷阱为什么会破坏签名解决方案
将 PDF 转为图像（PNG/JPEG）由于文件变为光栅图像，已签字节范围丢失。保留 PDF 副本用于法律用途，或将图像嵌入新 PDF 而不重新签名。
使用不同字符集重新编码 XML改变了规范化形式，导致哈希失效。保持原始 UTF‑8 编码，避免会改变空白的美化（pretty‑print）。
使用“优化” PDF 对象的转换器对象流被重写，修改了签名引用的对象 ID。关闭优化选项，选用提供 “preserve structure” 模式的转换器。
在转换前平面化表单字段表单字段值进入视觉层，导致字段级签名失效。保持字段可编辑，或在平面化后重新签名。
删除或重命名分离签名文件文档与 .p7s 的链接消失。更新文档元数据中的引用，或将签名打包进容器中。

实际场景

法律合同

律师事务所常收到通过 Adobe Sign 签署的合同。若合同需存入仅接受 PDF/A‑1 的企业 DMS，转换必须保留原始签名。上述工作流——先转换为 PDF/A‑3，再使用能够保留签名字典的 PDF/A‑1 转换工具——可确保合同仍具法律效力。

电子发票（PEPPOL）

欧洲电子发票使用 XML‑DSig 对发票进行签名。供应商可能需要把自有的 XML 架构转换为 PEPPOL BIS 格式。只要保留 <Signature> 元素并正确映射命名空间前缀，发票即可通过 PEPPOL 验证器，买方无需重新签名。

政府表单

许多公共部门表单采用分离式 CMS 文件签名。某部门将旧提交迁移到以 DOCX 存储的记录管理系统时，转换脚本会提取 CMS 签名、嵌入 DOCX 包中并更新引用表。审计员随后可对原始文档进行签名验证。

总结

在文件转换过程中保持数字签名不是事后补救，而是一套融合密码学认知、格式知识与慎重工具选型的系统化流程。通过识别签名类型、选取兼容的目标格式、采用提取‑保留‑重新嵌入的工作流，并利用自动化检查对结果进行验证，组织既能保持法律完整性，又能享受现代文件格式的灵活性。当工作流中包含 convertise.app 等云转换服务时，确认供应商尊重签名容器并遵循隐私‑by‑design 原则，可再添一层保障。最终，采用“验证优先”的系统化思路能够避免昂贵的重新签署循环，守护每一次电子签名中蕴含的信任。