PDF/A-3A 文档的 PAdES LTV 签名产生无效签名

Question

简介

我在对标记为符合 PDF/A - 3A 的 PDF 文档进行数字签名时遇到问题。使用 PDFBox（最新版本，2.0.24）我最终在 Adob​​e Acrobat 中得到一个无效签名，而使用 iText7（最新版本）我得到一个有效签名。目标是获得符合 PAdES LTV 的签名。

概述

我的过程如下（PDFBox 和 iText7）：

• 我打开 PDF，创建用于签名的哈希（要签名的数据）
• 我打电话给第 3 方服务来取回数字签名
• 在服务响应中，我还获得了 OCSP 和 CRL 内容，我需要在 PDF 中嵌入以提高 LTV 质量
• 我在 PDF 中嵌入了签名
• 我将文档保存到内存中，然后重新打开它以嵌入 OCSP 和 CRL
• 我嵌入了 OCSP 和 CRL 项，创建了各自的 DSS 和 VRI 字典
• 我将 PDF 保存到磁盘

对于 PDFBox，签名代码是 here，对于 OCSP/CRL 嵌入代码是 here。 对于 iText7，用于签名和 OCSP/CRL 嵌入的代码是here。

问题

现在，这适用于大多数 PDF 文件，包括多重签名文档。问题在于一个特定的 PDF，它被创建为 PDF/A compliat，级别 3A。

使用 PDFBox，如果我只是嵌入签名并在 Adob​​e Acrobet 中打开文档，则签名是有效的。如果我还嵌入了 OCSP/CRL 内容，则签名不再有效。 Adobe Acrobat 抱怨说：

签名无效：文档自签名后已被更改或损坏。

我也注意到，只是这样做：

document.load(inputStream);
document.save(outputStream);

我破坏了签名。根据我的测试，实际嵌入并不是问题的真正原因，而只是我在嵌入签名后重新打开 PDF 并将其保存回磁盘。

通过 iText7 使用相同的过程（密钥、证书等），我最终在 Adob​​e Acrobat 中获得了有效的 LTV 签名。

示例 PDF

示例文档为here。原件包含未签名的文档，然后有2个样本，一个用于PDFBox（在Adobe Acrobat中无效），一个用于iText7（在Adobe Acrobat中有效）。

到目前为止，我的研究表明，在签名嵌入后加载 PDF 时，PDFBox 以某种方式破坏了元素的顺序。它提示 this issue 加载和保存文档，尽管对于所有其他 PDF 我执行相同的过程并且 Adob​​e Acrobat 不会抱怨签名。

我还尝试使用 PDFBox 2.1.0-SNAPSHOT 和 3.0.0-SNAPSHOT，希望问题与 PDF 中元素的排序有关，并且已修复。不过，我得到了相同的结果。

稍后编辑 1

请看下面的后期编辑2，这里的后期编辑1不是个好主意！

根据@mkl 下面接受的答案，问题出在原始 PDF 文件上，其中包含分成几个小节而不是一个小节的交叉引用表。这似乎是由最初生成 PDF 的服务使用的库（Aspose PDF for .NET，版本 21.3 或更早版本）引起的。

似乎适用于我当前代码的一种解决方法如下：

PDDocumentInformation info = pdDocument.getDocumentInformation();
if (info != null && StringUtils.containsIgnoreCase(info.getProducer(), "Aspose")) {
try {
    pdDocument.save(inMemoryStream);
    pdDocument.close();
    pdDocument = PDDocument.load(inMemoryStream.toByteArray());
    inMemoryStream.reset();
} catch (Exception e) {

基本上，如果我检测到文档的创建者是 Aspose，我会将文档保存在内存中（通过 PDFBox 的 pdDocument.save()）并将其加载回来。这可确保交叉引用表在内存中正确写入，并且从那里签名和 OCSP+CRL 嵌入按预期工作，从而在 Adob​​e Acrobat 中生成有效签名。

稍后编辑 2

谢谢@mkl 和@TilmanHausherr，你是对的。假设使用某个库生成的所有文档都必须自动标准化并不是一个好主意，因为现有签名将失效。最后，更好的办法是保持代码不变，并期待一个正确构建的 PDF。修复创建位置的问题。

Answer 1

问题是由原始 PDF 中的错误引起的。您的 PDFBox 代码以附加模式（即增量更新）签名，因此签名版本中也存在错误。您的 iText 代码不会以附加模式登录，而是重写整个 PDF；这样做时，它不会出现与原始 PDF 的制作者相同的错误，因此该错误不再出现在签名版本中。 Adobe Acrobat 在使用更新验证签名时对此类问题非常敏感。

错误

PDF 中初始修订的交叉引用表不得拆分为单独的小节，但如果您的原始 PDF 已拆分：

0 75
0000000000 65535 f
0000000018 00000 n
...
0000313374 00000 n
0000313397 00000 n
76 20
0000313419 00000 n
0000313443 00000 n
...
0000846048 00000 n
0000846175 00000 n

this answer、this answer、this answer 和其他地方讨论了类似的情况；您还可以在这些答案中找到一些规范参考。

这通常会被忽视，Adobe Acrobat 在遇到 PDF 中的小问题时通常会非常松懈。

通常，也就是说，除了在签名修订后验证具有集成签名和增量更新的文档时，在这种情况下，Adobe Acrobat 经常认为此类问题是可疑的并且无法通过签名验证，即使它在签名修订后没有增量更新的情况下验证相同的 PDF 时不会抱怨。

您处于这种危急情况，您的最终文档包含签名修订后的增量更新，包含验证相关信息的更新。

谁造成了错误？

根据您原始 PDF 的 Info 字典，它是由“Aspose.PDF for .NET 21.3.0”生成的。已知 Aspose.PDF 的早期版本会创建此类错误的交叉引用表（请参阅first answer referenced above 的“损坏 PDF 的 PDF 处理器”部分）。显然 Aspose 还没有解决这个问题。