Valentin,
Valentin Ivanov wrote
In the light of this I wonder why in your case both the org.btrust.signer.PDFSigner (in initSignPDF() called by signPDF()) and com.lowagie.text.pdf.PdfPKCS7 (in the constructor called by PdfSigGenericPKCS.setSignInfo() which in turn is called by PdfSignatureAppearance.preClose) initialize a P11Signature for signing. Either you allow iText to create the signature or do it yourself externally.
no double signing is required, just the two exceptions are from SAME code but on different packages, I guess that is why you thought I double sign something in the code.
Are you sure? In the former case java.security.Signature.initSign is directly called by org.btrust.signer.PDFSigner.initSignPDF without any iText class at all in the call hierarchy, in the latter it is called by the com.lowagie.text.pdf.PdfPKCS7 constructor where according to the source code of that ancient iText version the Signature instance is non-public and internal.
Anyways, the p11 session handling is done automatically by pairs of initSign and sign. Thus, if you run out of sessions, there seem to be many Signature instances which are initialized for signing but never actually sign. If it is not the duplicate Signature instance initialization I suspected in my prior mail, i.e. if only iText PdfPKCS7 calls Signature.initSign(), then you appear to have very many iText PDF signing attempts discontinued after PdfPKCS7 instantiation and before signature creation.
I have never initialize "P11Signature" class by myself, this class is initialize internally by "java.security.Signature.initSign()".
When I said some software "initialized a P11Signature for signing", I left out the cryptographic stack for brevity's sake.
And about the injection, this is the code I am using to sign PDF (it is 100% the same like
HERE):
On the contrary, when I compare your code with the referenced sample, there are differences indeed! Your code:
PdfReader reader = new PdfReader("original.pdf");
[...]
sap.setCrypto(key, chain, null, PdfSignatureAppearance.WINCER_SIGNED);
[...]
PdfPKCS7 sig = sg.getSigner();
Signature sign = Signature.getInstance("SHA1withRSA");
sign.initSign(key);
sign.update(hash);
sig.setExternalDigest(sign.sign(), hash, "RSA");
PdfDictionary dic = new PdfDictionary();
byte[] ssig = sig.getEncodedPKCS7();
The sample:
[...]
PdfPKCS7 sig = sg.getSigner();
sig.setExternalDigest(null, hash, null);
PdfDictionary dic = new PdfDictionary();
byte[] ssig = sig.getEncodedPKCS7();
The sample uses "sig.setExternalDigest(null, hash, null)" which tells iText "Take this hash value and for everything else use the data you already have, especially sign the hash using the key I gave you in sap.setCrypto(key, ...)."
You use "sig.setExternalDigest(sign.sign(), hash, "RSA");" which tells iText "Take this hash value and this externally created signature, especially do not sign anything using the key I gave you in sap.setCrypto(key, ...)."
Thus, you initialize iText code for signing (which calls Signature.initSign() and, thus, requests a session) but then supply a signature yourself, making iText not use its Signature instance which, therefore, holds on to its session.
Here you have the duplicate Signature instance initialization I suspected in my prior mail.
Please could you tell me what line is injecting PrivateKey into iText?
sap.setCrypto(key, ...)
Do you want to tell me that neither Java Providers nor iText have not made opportunity to manually clean the resources? And rely on Java GC. I hope this will be changed in future, otherwise it sounds like a hit under the belt regarding Java language.
They rely on the GC only if someone forgets to use the session he initialized.
The only line i give PrivateKey to iText is PdfSignatureAppearance.setCrypto(PrivKey, chain, null, PdfSignatureAppearance.WINCER_SIGNED);
So you knew all along... ;)
In a nutshell: If you do "PdfSignatureAppearance.setCrypto(PrivKey, ...)", iText will do "Signature.initSign(PrivKey)" during preClose().
Am i the only one who is trying to sign thousands files?
I'm used to use cases with higher throughput.
Regards, Michael
Locked
