PDFSignature | Example on how to add a signature to a PDF using PDFKit | Document Editor library

The code in the question is based on a multi-phase approach:

• Sign the PDF injecting an empty byte array as signature container (by use of the ExternalBlankSignatureContainer).
• Calculate the digest to sign (here incorrectly a digest for the whole file from the previous step is calculated, the digest must be calculated for the whole file except the signature container placeholder).
• Request signature container for that document hash.
• Inject signature container into the placeholder in the file from the first step.

If the signature server can take a long time to return a signature container, such an approach is appropriate but in the case at hand comments clarify

The server gives response quickly(just few seconds)

In such a use case one should proceed in a single step approach (as far as iText signing API calls are concerned):

Your signDocument method apparently does not accept a pre-calculated hash value but seems to calculate the hash of the data you give it, in your case the (lower case) hex presentation of the hash value you already calculated.

In your first example document you have these values (all hashes are SHA256 hashes):

• Hash of the byte ranges to sign:

The most important part of your screenshot

is the text "1 Page(s) Modified" between the signatures on the signature panel. This tells us that you do other changes than merely adding and filling signature fields. Inspecting the file itself one quickly recognizes the change:

• In the original sample.pdf

  there is just a single content stream.

• In sample_signed.pdf with one signature

  there are three content streams, the original one enveloped by the new ones.

• In sample_signed_signed.pdf with two signatures

  there are five content streams, the former three enveloped by two new ones.

So in each signing pass you change the page content. As you can read in this answer, changes to the page content of signed documents are always disallowed. It doesn't even help that the contents of the added streams are trivial, each stream added in front contains:

So i finally found a working solution.

Link to day saving repo: https://github.com/crs2195/signature/tree/master/RemoteSignature-%20PDFBox/CSC-PDFBox

The iText 7 signing API attempts to hide implementation details which shouldn't be used anymore since the 5.3.x signature API overhaul, and the signature dictionary is such a detail.

For details on the signature API introduced in the 5.3.x versions, please read the iText Digital Signatures white paper. The Java examples in there have been ported to C# and can be accessed here.

First of all, you do not have to split the signing process like you do. I've seen a lot of questions in which the developers want to do this, but strictly speaking it is not necessary (well, under the hood iText still will first create a prepared PDF and later inject the signature container, but it can be kept under the hood).

Splitting the process only is necessary if the external signing service takes very long to create the signature and you cannot keep the PDF in memory for that time.

I'll look into both variants here.

If your external signing service returns the result (a full PKCS#7 signature container) fast enough, you should use this approach. The base code starts similar to yours:

Since the signature that I receive does not contain a timestamp from a timestamp server, can I embed such a timestamp at this point or should the remote web service add it before sending the signature to me?

Such a time stamp is added to the signature container as unsigned attribute. Because they are not signed, unsigned attributes in a signature container can be changed after applying a signature, e.g. additional ones can de added.

Thus, you yourself can in particular add a time stamp to the signature container retrieved from your service.

Depending on the nature of your signatures, though, you might have to increase the size of the placeholder you create in the pdf to have enough space for the additional time stamp.

There are a number of issues in your code.

First of all your code mixes different iText signing API generations. There is the older API generation which requires you to work very near to the PDF internals, and there is the newer (since version 5.3.x) API which is implemented as a layer over the older API and does not require you to know those internals.

The "Digital Signatures for PDF documents" white paper focuses on showing the newer API, only section 4.3.3 "Signing a document on the server using a signature created on the client" uses the old API because the use case does not allow for the use of the newer API.

Your use case does allow for the use of the newer API, though, so you should try and use only it.

(In certain situations one can mix those APIs, but you then should really know what you're doing and still can get it awfully wrong...)

But now some more specific issues:

The MakeSignature.Sign* methods implicitly close the underlying PdfStamper and SignatureAppearance objects, so working with those objects thereafter should not be assumed to result in sensible information.

But in GetBytesToSign you do

Analysis of file-signed-failed.pdf

In an ASN.1 dump of the contained signature container one issue immediately strikes the eye: The messageDigest attribute contains a copy of the signed attributes as they should be, i.e. with a proper messageDigest attribute: