使用CERTIFIED_NO_CHANGES_ALLOWED在附加模式下对串联的PDF进行签名 [英] Sign concatenated PDF in append mode with CERTIFIED_NO_CHANGES_ALLOWED

问题描述

我尝试使用附加模式和证书级别CERTIFIED_NO_CHANGES_ALLOWED对PDF进行签名，但是某些PDF文件显示为已修改，因此在Acrobat中无效.

I tried to sign PDF with append mode and certification level CERTIFIED_NO_CHANGES_ALLOWED but certain PDF files shown as modified and therefore invalid in Acrobat.

itext 5.5.6，代码:

itext 5.5.6, code:

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)

PDf file is created with wkhtmltopdf and concatenated with itself with pdfunite (CentOS 7)

以下是带有示例PDF的zip文件: https://www. dropbox.com/s/lea6r9fup6th44c/test_pdf.zip?dl=0

Here is zip with sample 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_g.pdf-原始签名文件，在Acrobat中看起来不错
Signed_2g.pdf-串联的签名文件，在Acrobat中看起来已损坏

g.pdf - original PDF
2g.pdf - concatenated version (pdfunite g.pdf g.pdf 2g.pdf)
signed_g.pdf - original signed file, looks OK in Acrobat
signed_2g.pdf - concatenated signed file, looks like corrupted in Acrobat

那是正确的行为，还是Acrobat，pdfunite，itext或我自己出错了?)))?

So is it correct behavior, or something goes wrong with Acrobat, pdfunite, itext or myself )))?

谢谢.

推荐答案

验证示例

Certifying the sample 2g.pdf using the OP's code and verifying the result with other tools than Adobe Reader one obtains the information that the certification signature is valid.

这样的事情(例如Adobe Reader抱怨一个完美有效的签名)通常发生在文档上，这会导致Adobe Reader在加载时操纵该文档.在这种情况下，Adobe Reader会检查更改后的文档中的签名，因此会看到无效的签名.此类操作尤其可能是无效文件的修复.

Something like this (i.e. Adobe Reader complaining about a perfectly valid signature) usually happens with documents which cause Adobe Reader to manipulate the document upon loading. In such a case Adobe Reader checks the signatures in the changed document and, therefore, sees an invalid signature. Such manipulations may especially be repairs of invalid files.

这里也是这种情况，

This also is the case here, 2g.pdf is not completely valid (even though in a way that PDF parsers usually ignore): Its cross reference table is segmented into multiple subsections:

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

但是分段的交叉引用表仅在进行增量更新时有效，而在初始文档修订版中无效，并且此文档被构造为初始修订版.

But segmented cross reference tables are valid only in case of incremental updates, not in case of initial document revisions, and this document is constructed as an initial revision.

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

For a file that has never been incrementally updated, the cross-reference section shall contain only one subsection, whose object numbering begins at 0.

( ISO 32000-1 )

因此，此细分表无效.

因此，我修复了交叉引用表，使其只包含一个小节(通过为省略的索引添加 f (三)条目):

So I fixed the cross reference table to contain but one sub-section (by adding f (ree) entries for the indices left out: 2g-fix.pdf . And indeed, certifying this document using the OP's code one gets a certification signature Adobe Reader (at least version XI I've currently installed here) is happy with.

所以这是使用增量更新的缺点:保留原始文档中的错误并必须对其进行处理...

So this is the disadvantage of using incremental updates: One keeps the errors of the original document and has to cope with them...

这篇关于使用CERTIFIED_NO_CHANGES_ALLOWED在附加模式下对串联的PDF进行签名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！