私は2つのpdf文書を認証しています（署名され、Itext 7に基づいて同じメカニズムで検証されています）、Adobe Reader DCを使用して正当性をチェックすると、緑色のマークが1つだけです。これらの2つのうち1つが署名され7つの有効な文書がAdobe DCリーダで有効でないのはなぜですか？
良い1： https://1drv.ms/b/s!AkF6t4TavwMvgxWaidlUqvPvHH1r
悪い1： https://1drv.ms/b/s!AkF6t4TavwMvgxQCMdGY61S1EvUh
よろしく
デビッド・L
これは、Adobeのバグではありません、それは機能です。
アドビが暗号検証を実行すると、署名が攻撃されたかどうかを確認するための追加チェックも実行されます。それはいくつかの容疑者を分析し、その分析結果が否定的になった場合、Adobeはエラーメッセージを表示します。これは、Adobeが分析と妥当性を誤って報告していることです。しかし、これらの隠された要件の回避策があります。
iTextは、第一には、ドキュメントを変更するために、非追加モードで使用された： 
残念ながら、具体的な例非追加モードで使用されるiTextは7に、仕様によって許可されない変更を導入し。問題は、iTextにサブセクションが導入されていることです。 、増分更新されていないファイルについては
7.5.4クロスリファレンス表 [...]：これは仕様は、あなたが行うことができますが、これは明示的に最初のリビジョンのために許可されていないものです[...]
以下は、iTextが非付加モードで使用された後の最初のリビジョンのxrefを見つけることになりますが、色付きの四角形はすべて新しいサブセクションです。これに準拠するには1つの矩形しかなければなりません。 
この は7月末を予定し、今後の7.0.4リリースで修正されます。
*これはAdobeのバグではありませんAdobeは、「この署名が適用されて以来、この文書に加えられた変更のいくつかは、文書作成者が許可していないものです」と同時に述べています。 「この署名が適用されて以来、この文書は変更されていません。これはバグではなく、ガーベッジ・イン*のケースであると主張することができますが、アドビはその妥当性を署名検証の成果として防止することを検討すべきです。 – mkl
それは本当です。私は先週、この混乱したレポートをアドビに報告しました。彼らがそれについて何かしているかどうかを見ていきます。 –
複数の他のツールがすべての問題なく、これらの二つの文書を検証しているので...私たちは、それは偽の読者のバグだと思うかもしれません。特に
Adobe Acrobatのは自分自身であると引き裂かれるが：
*同じ仕組みで - どのように正確にこの機構が設計されていますか？例えば。増分更新として署名していますか？ – mkl
こんにちは、この古い投稿を見て、方法を説明してください： –
https://stackoverflow.com/questions/39151230/in-itext-7-how-to-sign-a-pdf-with-2-steps –