itextsharp | [DEPRECATED] .NET port of the iText library, only security fixes will be added — please use iText 7 | Document Editor library

The PDF in the MemoryStream is not finished before document is closed. Thus, you store incomplete PDFs.

To fix this, move

You could match the last occurrence of Print Name: and then match as least as possible of the allowed chars until you encounter the same using a backreference until the end of the string.

Note that \s can also match a newline.

If you using iTextSharp Why don't do it all the way in iTextSharp?

Determining the Page Number

According to your code you already do have a page object, the PdfPage page, and are looking for its page number in the document. You can use the PdfDocument method

This

As already mentioned in a comment, the example document "InvalidDocumentSignedTwice.pdf" has the signature not applied in an incremental update, so here it is obvious that former signatures will break. But this is not the issue of the OP's example project. Thus, the issue is processed with an eye on the actual outputs of the example project.

Analyzing the Issue

When validating signed PDFs Adobe Acrobat executes two types of checks:

• It checks the signature itself and whether the revision of the PDF it covers is untouched.
• (If there are additions to the PDF after the revision covered by the signature:) It checks whether changes applied in incremental updates only consist of allowed changes.

The former check is pretty stable and standard but the second one is very whimsical and prone to incorrect negative validation results. Like in your case...

In case of your example document one can simply determine that the first check must positively validate the first signature: The file with only one (valid!) signature constitutes a byte-wise starting piece of the file with two signatures, so nothing can have been broken here.

Thus, the second type of check, the fickle type, must go wrong in the case at hand.

To find out what change one has to analyze the changes done during signing. A helpful fact is that doing the same using iText 5 does not produce the issue; thus, the change that triggered the check must be in what iText 7 does differently than iText 5 here. And the main difference in this context is that iText 7 has a more thorough tagging support than iText 5 and, therefore, also adds a reference to the new signature field to the document structure tree.

This by itself does not yet trigger the whimsical check, though, it only does so here because one outline element refers to the parent structure tree element of the change as its structure element (SE). Apparently Adobe Acrobat considers the change in the associated structure element as a change of the outline link and, therefore, as a (disallowed) change of the behavior of the document revision signed by the first signature.

So is this an iText error (adding entries to the structure tree) or an Adobe Acrobat error (complaining about the additions)? Well, in a tagged PDF (and your PDF has the corresponding Marked entry set to true) the content including annotations and form fields is expected to be tagged. Thus, addition of structure tree entries for the newly added signature field and its appearance not only should be allowed but actually recommended or even required! So this appears to be an error of Adobe Acrobat.

A Work-Around

Knowing that this appears to be an Adobe Acrobat bug is all well and good, but at the end of the day one might need a way now to sign such documents multiple times without current Adobe Acrobat calling that invalid.

It is possible to make iText believe there is no structure tree and no need to update a structure tree. This can be done by making the initialization of the document tag structure fail. For this we override the PdfDocument method TryInitTagStructure. As the iText PdfSigner creates its document object internally, we do this in an override of the PdfSigner method InitDocument.

I.e. instead of PdfSigner we use the class MySigner defined like this:

When you are wondering about details of the PDF format, you should have a look into the PDF specification ISO 32000.

Operands Operator Description array TJ Show one or more text strings, allowing individual glyph positioning. Each element of array shall be either a string or a number. If the element is a string, this operator shall show the string. If it is a number, the operator shall adjust the text position by that amount; that is, it shall translate the text matrix, T_m. The number shall be expressed in thousandths of a unit of text space (see 9.4.4, "Text Space Details"). This amount shall be subtracted from the current horizontal or vertical coordinate, depending on the writing mode. In the default coordinate system, a positive adjustment has the effect of moving the next glyph painted either to the left or down by the given amount. Figure 46 shows an example of the effect of passing offsets to TJ.

(ISO 32000-1, Table 109 – Text-showing operators)

Thus,

I'm suspecting that the numbers between the literal characters (e.g -1688.21,-492.975,...), may be useful, but I didnt find explanation about such parameters.

What they represent?

For each such number, the operator adjusts the text position by that amount. The number is expressed in thousandths of a unit of text space. This amount is subtracted from the current horizontal or vertical coordinate, depending on the writing mode.

Just like @mval mentioned in a comment, iText uses the public key algorithm OID as signature algorithm OID.

In case of RSA that is ok as here the same OID is specified for a RSA key and for RSASSA (with PKCS#1 v1.5 padding).

This is not the case for ECDSA, so eSignature DSS complains. Adobe Acrobat (Reader) on the other hand is very lax. It actually ignores the signature algorithm OID field, you could even have an ECDSA signature with the RSA OID in that field and the current Acrobat wouldn't complain.

To fix this use an IExternalSignatureContainer implementation instead of an IExternalSignature implementation and call MakeSignature.SignExternalContainer instead of MakeSignature.SignDetached. In your IExternalSignatureContainer implementation you can use BouncyCastle or Windows Crypto API classes to create a CMS signature container.

Other questions related to incorrect signature algorithm OIDs in respect to iText:

• ECDSA signed PDF fails signature verification with iText 7 (C#), but succeeds with Adobe Reader DC
• C# Itext7 signed pdf signature is invalid in Foxit PDF Reqader but valid in Acrobat reader

With PDF4NET you can extract the XMP metadata without loading the entire document in memory: