32
Replies
I'm having a similar problem, trying to do multiple signatures in my test environment. What could be the issue and possible fix?
In your example file the initial revision (containing the first signature) has been re-saved after signing (not applying changes in an incremental update but completely re-writing the PDF). This not only changed the signed byte range contents but also moved the signature dictionary (rendering the ByteRange entry itself incorrect) and changed the size of the single-revision PDF (making the ByteRange not covering a whole revision anymore). Furthermore, the software doing this re-write has an error in its cross reference table writing code.
Thus, the first signature in your document must be reported as broken.
After that first revision with the broken first signature there are a number of additional revisions (saved using incremental updates) to apply a second signature:
- (Update 1) Adding an empty signature field
- (Update 2) Adding an appearance to the new empty signature field
- (Update 3) Signing the new signature field
At first glance these steps look ok.
So you should check which code in your setup broke the initial PDF and fix that.
But, when I open the PDF in Acrobat Reader, I see a bunch of validation failures.. Attaching the sample pdf for reference.
Which bunch of validation failures? I only see one:
Looking into it, though, a number of issues become obvious:
- There is no signature container embedded in the signature field value, instead the placeholder is filled with 0x00 bytes. This explains the message by Acrobat, a sequence of 0x00 bytes is not a valid signature container.
- The gap in the ByteRange array starts at offset 482900. but the actual signature placeholder starts at offset 11036. This is not just off-by-1 or so, it's completely different.
- The second range in the ByteRange array ends at offset 511033 but tghe file size is just 509215.
The first item indicates that the PDF has only been prepared for signing but no signature container has actually been embedded. The latter items indicate that after preparing for signing the PDF has again been opened and then saved regularly and not as a new revision by appending an incremental update.
The PDFBox example signing code does neither of these errors. Thus, please have a look at the PDFBox examples and do as they do.
password; RSAI2015
EAadhaar_2726511120312820241001164100_0201202511345.pdf
By @duraimobiles_9170
The file you shared is not a valid PDF file. It is the concatenation of two PDF files, the first 1390126 bytes are the first PDF (attached here as EAadhaar_2726511120312820241001164100_0201202511345-001.pdf) and the remaining 1410701 bytes are the second PDF (attached here as EAadhaar_2726511120312820241001164100_0201202511345-002.pdf). Actually the second PDF is a copy of the first with a signature attached.
If you open the second PDF in Acrobat, you'll see that it accepts the signature (if you happen to have configured it to trust the "DS Unique Identification Authority of India 05" signer certificate or one of its chain of issuer certificates).
Concatenating two valid PDFs does not create a valid new PDF. So when loading your full file, Acrobat has to repair it. But repairing a PDF usually results in a file that is internally considerably different from the original file. Thus, Acrobat will display the signature as invalid.
AdChoices