Issue with PreSigned PDF in WebViewer

w.bonazzoli · January 3, 2025, 3:44pm

WebViewer Version: 10.10.1

Do you have an issue with a specific file(s)? No
Can you reproduce using one of our samples or online demos? Yes
Are you using the WebViewer server? No
Does the issue only happen on certain browsers? No
Is your issue related to a front-end framework? No
Is your issue related to annotations? Yes

Please give a brief summary of your issue:

Load a PDF inside the webviewer, without breaking pre-existing signatures

Please describe your issue and provide steps to reprodu
testTUTTI CAMPI firmati non loccato.pdf (107.7 KB)
ce it:

I have a pdf containing a valid signature (signed on the backend side via the “PDFTron.NET.x64” Version=“11.1.0” library in the demo environment)

Loading that pdf into the webviewer and downloading it immediately, the pre-existing signature is invalid.

Using PDFTron.NET.x64 without WebViewer we can, given a pdf with a valid signature, add a signature type acrofield and sign it without breaking the pre-existing signature.

Is it possible from the webviewer to add an acrofield without breaking a pre-existing signature?

Please provide a link to a minimal sample where the issue is reproducible:

I attach a sample pdf with which I did the tests

The issue can be replicated using your demo
https://sdk.apryse.com/samples/web/samples/full-apis/ViewerDigitalSignatureValidationTest/

kkim · January 3, 2025, 6:20pm

Hi there,

Is it possible from the webviewer to add an acrofield without breaking a pre-existing signature?

This will depend on the permission settings by the signature field. You can see the list of permissions that you can set on the digital signatures here:
https://sdk.apryse.com/api/web/Core.PDFNet.DigitalSignatureField.html#.DocumentPermissions__anchor

Best regards,
Kevin Kim

w.bonazzoli · January 7, 2025, 2:43pm

From your answer I don’t understand how to download, from the webviewer, a previously signed document correctly without breaking the signature.

I add that even in your demo page linked above, if I download a document with a valid signature, then immediately reload the document in the webviewer, the signature is corrupted.

Thankyou for your support,
William

kkim · January 7, 2025, 9:15pm

Hi there,

This actually fails on the sample demo for 2 reasons:

The file is not incrementally saved, i.e.
instance.UI.downloadPdf({ flags: instance.Core.SaveOptions.INCREMENTAL });
Using the download button doesn’t automatically save the file as incremental, so you will need to set this explicitly.
The sample page will add a watermark to the document, which is considered making a change on the document.
If you use a registered license, the signature should remain valid.

Best regards,
Kevin Kim

w.bonazzoli · January 8, 2025, 11:23am

Hello,
I tried to implement your solution, on a webviewer with a valid license, but it doesn’t work

These are my tests

1) Listening to onDocumentLoad() and immediately downloading the document: the pre-existing signature works correctly
saveSettings FLAG doesn’t seems to make differences. I tested no flag, flag INCREMENTAL, or LINEARIZED and i get the same result

this.instance.Core.documentViewer.addEventListener('documentLoaded', async () => {
    this.instance?.UI.downloadPdf({ flags: this.instance?.Core.SaveOptions.INCREMENTAL 
});

2) Listening to onDocumentLoad(), change to editAnnotationView and downloading the document: the pre-existing signature breaks

My Code:

this.instance.Core.documentViewer.addEventListener('documentLoaded', async () => {
            this.switchToEditAnnotationsView();
            setTimeout(() => {

                // CHECK IMAGE - RESULT IF I DOWNLOAD IT WITH SaveOptions.INCREMENTAL
                this.instance?.UI.downloadPdf({ flags: this.instance?.Core.SaveOptions.INCREMENTAL});

                // CHECK IMAGE - RESULT IF I DOWNLOAD IT WITH SaveOptions.LINEARIZED
                // this.instance?.UI.downloadPdf({ flags: this.instance?.Core.SaveOptions.LINEARIZED});

            }, 1000);
        });

// even manually clicking on data-element="signatureFieldToolGroupButton" I get the same result
switchToEditAnnotationsView() {
        const iframeDocument = this.getIframeDocument();
        if (iframeDocument) {
            const buttonForme = iframeDocument.querySelector('.ribbon-group') as HTMLElement;
            buttonForme.click();
            const div = iframeDocument.querySelector('.tool-group-button') as HTMLElement;
            if (div?.children.length) {
                const button = div.children[0] as HTMLElement;
                if (button) {
                    button.click();
                    button.click();
                }
            }
        }
    }

// RESULT IF I DOWNLOAD IT WITH SaveOptions.INCREMENTAL

// RESULT IF I DOWNLOAD IT WITH SaveOptions.LINEARIZED

kkim · January 8, 2025, 7:30pm

Hi there,

2) Listening to onDocumentLoad(), change to editAnnotationView and downloading the document: the pre-existing signature breaks

When you switch to this view on WebViewer (form field creation mode), the annotations you see on the document are added as temporary annotations. This would be considered making a change to the document hence breaking the signatures.

Starting from version 11.0, there are no temporary annotations and should not be triggering the annotationChanged events:

Best regards,
Kevin Kim

w.bonazzoli · January 9, 2025, 10:28am

Hi, is there any way to fix this while staying on v10? I can’t update the library now

Thankyou

kkim · January 9, 2025, 8:14pm

Hi there,

If you change the permission settings on the DigitalSignatureField before adding the certificate, then it will stay valid even if the annotations have been added to the document:
https://sdk.apryse.com/api/web/Core.PDFNet.DigitalSignatureField.html#.DocumentPermissions__anchor

Unfortunately, this was a major change that was added to 11.0 and cannot be ported back. I recommend. you not to switch to the formfield creation mode.

best regards,
Kevin

w.bonazzoli · January 27, 2025, 1:43pm

Hi, I’ve updated to version 11.2, but the signatures are still getting corrupted. Essentially, I’m experiencing the same issue as before the update. I’ve tested with PDFs containing valid signatures, such as the attached file, but after loading it into the WebViewer and downloading it, the signature becomes invalid.

How can I add an Acrofield signature without breaking the existing signatures through the WebViewer?

Thank you for your support!

Best regards,
William

kkim · January 27, 2025, 7:56pm

Hi there,

We have a working sample of digital signature here:
https://sdk.apryse.com/samples/web/samples/full-apis/#:~:text=demo%20View%20Source-,DigitalSignature,-Demonstrates%20how%20to

If I take the ‘waiver_custom_signed.pdf’ from the result and open/download it on the showcase, you can see that the certification still shows has unmodified, with the digitalSignaturePermission setting at 3:

For that particular document, the permissions are also at 3, but it breaks on download. Could you please share how those fields were created/signed?

best regards,
Kevin

w.bonazzoli · January 28, 2025, 3:27pm

Hi Kevin,

Thank you for your reply.

I have tested the WebViewer v11.2 with the incremental download option immediately after loading the document. Unfortunately, the signatures still become broken as soon as I download the document after loading it, even with the incremental save flag.

instance.UI.downloadPdf({ flags: instance.Core.SaveOptions.INCREMENTAL });

To give you more context, I tested this with the two sample documents available here:
https://sdk.apryse.com/samples/web/samples/full-apis/ViewerDigitalSignatureValidationTest/
i downloaded the documents directly from this links

Both documents show the same issue, where the signatures are broken after downloading them immediately after loading into the WebViewer.
tiger_withApprovalField_certified_approved_ORIGINAL.pdf (51.1 KB)

This issue is blocking for us, as we need to maintain the integrity of existing signatures while adding new ones (e.g., Acrofield). Could you kindly assist in resolving this? The signatures should remain intact after the document is downloaded and reloaded into the WebViewer.

Thank you again for your support!

Best regards,
William

kkim · January 29, 2025, 4:26pm

Hi there,

Thank you for your reply,

Using the tiger_withApprovalField_certified_approved_ORIGINAL.pdf, this is the status on the UI:

And with the snippet used:

(async () => {
  const doc = documentViewer.getDocument()  
  const pdfDoc = await doc.getPDFDoc();
  const digsig_fitr = await pdfDoc.getDigitalSignatureFieldIteratorBegin();
  const DocumentPermissions = {
    1: 'e_no_changes_allowed',
    2: 'e_formfilling_signing_allowed',
    3: 'e_annotating_formfilling_signing_allowed',
    4: 'e_unrestricted',
  };
  for (; await digsig_fitr.hasNext(); await digsig_fitr.next()) {
    const curr = await digsig_fitr.current();
    const docPerms = await curr.getDocumentPermissions();
    const hasCryptographicSignature = await curr.hasCryptographicSignature();
    if (hasCryptographicSignature) {
      console.log(DocumentPermissions[docPerms]); 
    }
  }
  return;
})();

We can see that there are two fields with e_annotating_formfilling_signing_allowed permissions

Using a valid license & Incremental download, reloading on WebViewer shows the same result:

The demo sample page will fail with the watermark being applied, which is considered a change in the document.
Could you please try with version 11.2.0 (latest) of WebViewer and see if you can reproduce the same result?

best regards,
Kevin

w.bonazzoli · January 30, 2025, 5:13pm

Hi Kevin,

Thank you for your response and for your support.

I have tested your latest suggestion, and indeed, the behavior aligns with what you described. When using incremental saving with a valid license, reloading the document in WebViewerand running your script in console, i get e_annotating_formfilling_signing_allowed as expected.

However, I have noticed an issue when opening the same downloaded document in Adobe Acrobat. Specifically:

In WebViewer (Apryse), after downloading the document with SaveOptions.INCREMENTAL, the signature field permissions still report e_annotating_formfilling_signing_allowed, which matches the original permissions.
However, when I open the same document in Adobe Acrobat, the signatures appear as corrupted/invalid.

This discrepancy is problematic for us, as we need to ensure that the digital signatures remain valid not only in WebViewer but also in Adobe Acrobat and other standard PDF readers.

Do you have any insights into why Adobe is detecting the signatures as invalid after downloading from WebViewer? Is there a specific setting or approach we should follow to ensure full compatibility?

Looking forward to your feedback.

Best regards,
William

kkim · January 30, 2025, 5:42pm

Hi there,

Thank you for your reply,

This is what I see on Adobe Acrobat before downloading it on WebViewer:

This is what I see after downloading it on WebViewer with Incremental Save / valid license:

The signature panel shows the same result, and I do not see any ‘corrupted/invalid’ warnings, just the validity of the cert is unknown, and author could not be verified.

If you are wondering about the triangular caution symbol, it is the similar to the yellow warning symbol reported on WebViewer:

To get rid of this warning, you can add a certification to the fields.
You can do this via our guide here:

We also have a set of recommended blogs for reference:

best regards,
Kevin

w.bonazzoli · January 31, 2025, 10:50am

Hello,

I was able to replicate the issue exactly as described. The pre-existing signatures remain valid only if the "toolbarGroup-Forms" is not selected. However, as soon as "toolbarGroup-Forms" is enabled, the signatures break.

This is a major issue for us because we must keep form functionality active to allow users to create additional AcroFields. The final PDF needs to contain both the previously signed AcroFields and the newly created ones, all with valid signatures.

We were previously informed that updating to v11.2 would resolve this issue. However, the problem persists. How can we achieve this workflow without breaking the pre-existing signatures?

To support our findings, I have attached images below that demonstrate the issue.

Looking forward to your guidance on implementing a proper solution.

Best regards,
William

w.bonazzoli · February 3, 2025, 3:57pm

Dear Kevin,

This issue remains critical for our organization. Pre-existing signatures break when “toolbarGroup-Forms” is enabled, preventing us from adding AcroFields without invalidating signatures.

Despite updating to v11.2, the problem persists. We urgently need a solution or workaround to maintain both existing signatures and new form fields.

Please advise on how to resolve this.

Best regards,
William

kkim · February 3, 2025, 8:09pm

Hi there,

Thank you for your reply and the steps taken, I was able to reproduce the issue.

It looks like clicking on Forms mode makes changes to form fields hence showing up as ‘altering’ the document on Adobe.

Because the original document permissions has a setting of 3 (e_annotating_formfilling_signing_allowed) this means that making changes to form fields is not permitted and seems to be causing the issue.

Prior to version 11, this was happening as expected due to the placeholders, but I have created a ticket for this issue for the product team to review and prioritize.

If the signature is not already signed, you should be able to set the permissions to ‘unrestricted’ (security setting 4) to get around this issue for now.

Best regards,
Kevin