在附加模式下使用CERTIFIED_NO_CHANGES_ALLOWED签署串联的PDF

Question

我尝试使用append模式和Certificate level CERTIFIED\u NO\u CHANGES\u签署PDF，但某些PDF文件显示为已修改，因此在Acrobat中无效。

itext 5.5.6，代码：

PdfStamper stp = PdfStamper.createSignature(reader, os,'\0',null,true);
PdfSignatureAppearance app = stp.getSignatureAppearance();
app.setCertificationLevel(PdfSignatureAppearance.CERTIFIED_NO_CHANGES_ALLOWED);

PDf文件使用wkhtmltopdf创建，并使用pdfunite（CentOS 7）将其自身连接起来

以下是zip和示例PDF：https://www.dropbox.com/s/lea6r9fup6th44c/test_pdf.zip?dl=0

g、 pdf-原始pdf
2g。pdf-连接版本（pdfunite g.pdf g.pdf 2g.pdf）
signed\u g.pdf-原始签名文件，在Acrobat中看起来正常。pdf-串联签名文件，在Acrobat中看起来已损坏

那么，这是正确的行为，还是Acrobat、pdfunite、itext或我自己出了问题）？

谢谢

Answer 1

验证样品2g。pdf使用OP代码并使用Adobe Reader one以外的其他工具验证结果，即可获得认证签名有效的信息。

类似的情况（即Adobe Reader抱怨完全有效的签名）通常发生在文档中，导致Adobe Reader在加载时操纵文档。在这种情况下，Adobe Reader会检查更改文档中的签名，因此会看到无效的签名。这种操作尤其可能是修复无效文件。

这里也是这种情况，2g.pdf不是完全有效的（即使PDF解析器通常忽略的方式）：它的交叉引用表被分段为多个子部分：

xref
0 1
0000000001 65535 f
3 2
0000000015 00000 n
0000000107 00000 n
6 41
0000000146 00000 n
...
0000015682 00000 n
48 14
0000015864 00000 n
...
0000025433 00000 n
66 2
0000025455 00000 n
0000025548 00000 n
69 41
0000025588 00000 n
...
0000041144 00000 n
111 14
0000041327 00000 n
...
0000050929 00000 n
126 4
0000050952 00000 n
0000051004 00000 n
0000051075 00000 n
0000051242 00000 n

但是分段交叉引用表仅在增量更新的情况下有效，而在初始文档修订的情况下无效，并且该文档被构建为初始修订。

对于从未进行增量更新的文件，交叉引用部分应仅包含一个子部分，其对象编号从0开始。

（ISO 32000-1第7.5.4节交叉引用表）

因此，这个分段表是无效的。

因此，我将交叉引用表固定为只包含一个子部分（通过为遗漏的索引添加f（ree）条目：2g fix）。pdf。事实上，使用OP的代码认证此文档时，Adobe Reader（至少是我目前安装的XI版本）会得到一个认证签名。

因此，使用增量更新的缺点是：保留原始文档的错误，并且必须处理这些错误。。。