[
https://issues.apache.org/jira/browse/PDFBOX-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14950064#comment-14950064
]
Rafael Gomez commented on PDFBOX-3011:
--------------------------------------
Done. It works for me.
I never mentioned that I also built and executed the non-visual CreateSignature
example when I started working with PDFBox. Both 1.8.10 and trunk worked for
me. At that time, I noticed the differences between the implementation of the
SignatureInterface.sign interface method in both CreateSignature and
CreateVisibleSignature examples. My not accurate enough code reading led me to
believe that the SignatureInterface.sign implementation on CreateSignature
example did add the whole certificate chain to the CMS.SignedData.certificates
collection. So that's why I picked the SignatureInterface.sign implementation
on CreateSignature example and used it on my "mix" example. Now that I did read
more carefully, I see that only the end-user (cert[0]) certificate is included
in the collection.
To continue learning:
1) How did you manage to see the BER-decoding error?
2) I've read PDFBOX-1822 but I must have missed something: why were those
BC-related changes needed? (i.e. addition of JcaCertStore,
JcaContentSignerBuilder, JcaSignerInfoGeneratorBuilder,
JcaDigestCalculatorProviderBuilder)
> Find out why trunk CreateVisibleSignature example produces incorrect output
> pdf
> -------------------------------------------------------------------------------
>
> Key: PDFBOX-3011
> URL: https://issues.apache.org/jira/browse/PDFBOX-3011
> Project: PDFBox
> Issue Type: Task
> Components: Signing
> Affects Versions: 2.0.0
> Environment: OS X Yosemite on MBP 2,6 GHz Intel Core i7, 16 GB 1600
> Mhz DDR3
> java version "1.7.0_45"
> Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
> Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
> Reporter: Rafael Gomez
> Fix For: 2.0.0
>
> Attachments: mix_example_correct_signed_pdf,
> quicksort_signed-bad.pdf, quicksort_signed-good.pdf,
> trunk_createvisiblesignature_example_incorrect_signed_pdf
>
>
> To evaluate Apache's PDFBox library, I created a simple sample based on trunk
> CreateVisibleSignature and CreateSignature. The reason for combining those 2
> samples was that each provided features that I wanted to test. The created
> "mix" example is in SignPDFPoC.java.
> The initial problem I faced is related to the sentence closing the
> SignatureOptions right before calling saveIncremental on the relevant
> document object. Once I moved the 'options.close()' sentence to a better
> position (see PDFBOX-3010), SignPDFPoC started to produce correct output,
> signed, pdf files. And once I added my test certificate chain to the trusted
> identities, the signature validates correctly.
> After examining the produced, signed, pdf, both via Signature Panel on Adobe
> Reader and via the file itself (binary), I got stuck on "Field: Signature1".
> I initially supposed that PDVisibleSignDesigner.signatureFieldName was used
> for that purpose. But it does not seem to be the case. Moreover, for
> invisible signatures, no PDVisibleSignDesigner is used, so there must be a
> different way.
> So I decided to build and execute the original CreateVisibleSignature from
> trunk to check whether it did something different regarding "Field:
> Signature1" that I could have missed in my "mix" example. This is how I found
> out that the trunk CreateVisibleSignature example produces incorrect pdf
> files. Or I must be doing something terribly wrong that, in advanced, I
> apologize for.
> I attach complete zip files for reproducing the observation:
> - mix_example_correct_signed_pdf
> - trunk_createvisiblesignature_example_incorrect_signed_pdf
> Simply add the .zip suffix, unpack and run the corresponding _execute.sh
> script. There are already .class files available. The needed dependencies are
> also present. As test p12 containing a certificate chain, test pdf file and
> test image.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
