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

Question

介绍

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

概述

我的流程如下（同时使用 PDFBox 和 iText7）：

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

对于 PDFBox，签名代码在这里，OCSP/CRL 嵌入代码在这里。对于 iText7，签名和 OCSP/CRL 嵌入的代码在这里。

问题

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

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

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

我还注意到，只需执行以下操作：

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

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

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

示例 PDF

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

到目前为止，我的研究表明，在签名嵌入后加载 PDF 时，PDFBox 以某种方式打破了元素的顺序。它暗示了加载和保存文档的这个问题，但对于所有其他 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

在这个答案、这个答案、这个答案和其他地方已经讨论过类似的案例；您还可以在这些答案中找到一些规范参考。

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

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

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

谁造成了错误？

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