PDF support API modifying document to break signature signing

Posted by: thill on 22 September 2025, 10:26 am EST

  • Posted 22 September 2025, 10:26 am EST

    We are running the GrapeCity PDF viewer with the ASP.NET GcPdfViewerController. Our workflow is as follows:

    1. Present the PDF in the front end to user 1. Create a stamp annotation containing the user’s signature on the front end.
    2. On our back end (not using the GcPdfViewerController), find that annotation and convert it to a signature field and sign it with our certificate, taking the appearance of the stamp and applying it to the signature field)
    3. Present it to user 2, and apply a second stamp annotation containing the user’s signature.
    4. Convert the second stamp annotation to a signature field again and sign it.

    Note that the permissions on the first signature are FormFillingAndAnnotations, so the stamp annotation in step 3 should be an allowed operation.

    However, we found what we believe to be a bug in the GcPdfViewerController: when the signed signature passes through the Modify() endpoint anywhere in step 3, it breaks the encryption for the existing signed signature. When comparing the contents of the PDF before and after it hits the Modify() endpoint, the order of the fields gets arbitrarily reordered, which is a change NOT covered by FormFillingAndAnnotations, and our attempts to undo that change in a reliable way have been very troublesome. This is proving to be a major issue for our product.

    Is there anything we can do? This really seems like a bug that needs to be addressed in the GcPdfViewerController.

  • Posted 23 September 2025, 11:42 am EST

    Hi Taylor,

    We could not replicate any issue with Step 3. The stamp annotation is added to the PDF document as expected. And on saving the document through the Modify endpoint, the encryption for the existing signature (generated in Step 2) is maintained.

    Please note that the digitally signed PDF document should be saved with the incremental update mode; otherwise, the signature will break.

    Furthermore, we could not reproduce that the form fields are arbitrarily reordered in the PDF document during the save operation. Please refer to the attached code sample and the working video that performs all the defined steps (see below).

    In case the issue does not resolve on your end, please share the following details with us:

    1. A stripped-down frontend and backend application replicating the issue. You can also modify and share the attached samples.
    2. A demonstration video of the issue.

    Kind Regards,

    Chirag Gupta

    Attachments:

    1. Frontend: DsPdfViewerApp.zip
    2. Backend: DsPdfSignatureApp.zip

    Working: https://drive.google.com/file/d/1JbVtfrc3iCJmjj_wrg2mu9lyCvb-BCn4/view

    References:

    1. Add multiple signatures: https://developer.mescius.com/document-solutions/dot-net-pdf-api/docs/online/Features/IncrementalUpdate#add-multiple-signatures
    2. Signing a signed PDF preserving the validity of the original signature: https://developer.mescius.com/document-solutions/dot-net-pdf-api/demos/features/signatures/sign-incremental/code-cs

    Disclaimer: Please note that in the working demonstration, the first signature is invalidated on signing the document second time because license headers are added to the PDF document, invalidating the first signature. However, the issue disappears in a licensed GcPdfDocument.

  • Posted 3 October 2025, 1:59 pm EST - Updated 3 October 2025, 2:06 pm EST

    How can I be sure all the pieces are licensed? We have a current subscription, but are not totally sure if the licensing keys are set up correctly. Is there an easy way to tell, or would I first learn about it by the signature becoming invalid in this case? I do not have the red text telling me to get a license on the outputted document in our development system when signing via code or opening in the viewer. I also do not get a NotLicensed exception at any point, either in your code (which is unlicensed and does output the red text) or mine.

    I get an error running your signing code: Can’t get private key from certificate. Inner exception: Keyset does not exist.

    However, switching to my own generated test pfx file reproduces some behavior using the pdf you included for signing, such as invalidating the original signature. I need to determine if it’s because of licensing or the field ordering issue I mentioned. However, in my code, the signature image disappears, which might be a clue that it is separate than licensing. I am still working on figuring out the exact differences, and will respond with more. In the meantime, if you could provide steps I could follow to determine if I am licensed correctly, that would be great. Thanks for the timely follow-up! We greatly appreciate the assistance.

  • Posted 6 October 2025, 4:56 am EST

    Hi Taylor,

    Apologies for the delay caused over the weekend.

    Regarding your licensing question - since you’re not seeing the red “license” watermark or any NotLicensed exceptions, your GcPdfDocument component is correctly licensed. The watermark only appears when the product is unlicensed, and a missing license key does not affect the validity of a digital signature. Licensing impacts only visual watermarks or runtime exceptions, not the cryptographic behavior of signatures.

    You can confirm the license registration by ensuring your project includes valid license assignments, for example:

    GcPdfDocument.SetLicenseKey(“DsPdf-License-Key”);

    DsPdfViewer.LicenseKey = “DsPdfViewer-License-Key”;

    Regarding the error:

    “Can’t get private key from certificate. Inner exception: Keyset does not exist.”

    This occurs because the PFX file provided in our shared sample isn’t trusted on your system, or the private key isn’t accessible under your current user account. To fix this, please run the PFX file on your system for the Current User and import and trust the certification.

    As for the disappearing signature image, we were able to reproduce this when the backend (GcPdfDocument) is licensed correctly, but the frontend (DsPdfViewer) is not. In such cases, the unlicensed viewer modifies the appearance streams when saving, which can cause the visual signature to disappear, even though the underlying signature data remains intact. To resolve this, please ensure that both GcPdfDocument and DsPdfViewer are licensed in your backend and frontend applications, respectively.

    Once both components are licensed, the signature image should remain intact. If the issue persists even after verifying licensing, please share a minimal stripped-down sample or update the one we previously provided so that we can investigate further.

    Kind Regards,

    Chirag Gupta

    References:

    1. DsPdfViewer Licensing: https://developer.mescius.com/document-solutions/dot-net-pdf-api/docs/online/pdfviewer/licensingandredistribution
    2. DsPdf Licensing: https://developer.mescius.com/document-solutions/dot-net-pdf-api/docs/online/GettingStarted/licenseinfo
  • Posted 6 October 2025, 9:53 am EST - Updated 6 October 2025, 10:58 am EST

    Thank you for the response, Chirag. As for the front end (DsPdfViewer), is there a way to tell if it’s licensed properly, aside from the appearance streams being modified? You said since we’re not getting the red text, the GcPdfDocument library is licensed correctly, but is there a way to know visually from the DsPdfViewer whether it’s licensed correctly?

  • Posted 6 October 2025, 9:57 am EST - Updated 6 October 2025, 10:58 am EST

    (ignore this message)

  • Posted 7 October 2025, 12:34 am EST

    Hi Taylor,

    You’re welcome!

    Yes, there’s a simple way to confirm whether the DsPdfViewer is licensed correctly. Please refer to the following scenarios where the DsPdfViewer is licensed:

    1. Evaluation License: An Evaluation watermark will be displayed at the bottom of each page in the DsPdfViewer as illustrated on the DsPdfViewer Licensing Page.
    2. Production License: No watermark will be displayed.
    3. Unlicensed: When unlicensed, the watermark at the bottom left will be - Powered by Document Solutions PDF Viewer. You can only deploy this EVALUATION version locally. Temporary deployment keys are available for testing.

    Your DsPdfViewer is licensed correctly if you see the Evaluation watermark or no watermark.

    Please let us know if you require any further assistance.

    Kind Regards,

    Chirag

    References:

    1. DsPdfViewer Licensing Page: https://developer.mescius.com/document-solutions/dot-net-pdf-api/docs/online/pdfviewer/licensingandredistribution#:~:text=Powered%20by%20Document%20Solutions%20PDF%20Viewer.%20Your%20temporary%20deployment%20key%20expires%20in%20[x]%20days.'
Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels