As it turned out the main problem was not whether or not the changes applied after the first signature were allowed or not, the problem was that these changes were added to the file using a normal save.
Such a normal save can completely change the order in which PDF objects are stored in the PDF file. Consequentially such a normal save damages the first signature beyond repair as its alleged signed byte ranges have changed and the signature value is not located in the gap between those ranges anymore either.
Thus, whichever changes you apply to a signed document, make sure you store them as an incremental update!
That being said, though, it is difficult to use the PDFBox incremental update mechanism for anything else than what it was designed for, i.e. anything but adding additional signatures. You have to mark the low level objects you changed including a chain of objects from the document catalog to them, so you must in particular understand how exactly your changes are implemented on a very low level. Furthermore, this mechanism often requires you to save more objects than actually have changed to to the "chain from the catalog" criterion.
Overlay
class or something overlaying in an arbitrary manner? – mklOverlay
class does is never allowed in already signed documents because theOverlay
class manipulates page content which is forbidden for any kind of signed document. – mkl2_Signed.pdf
, is not a certification signature (Adobe Reader in case of documents whose first signature is merely an approval signature assumes an equivalent of the most liberal certification which might have made you think it is a certification signature). And then your problem concerning the first signature is not merely that you applied disallowed changes in an incremental update as was expected here. You actually saved the file normally after usingOverlay
, not using an incremental update. This completely breaks – mkl