node-signpdf | Simple signing of PDFs in node | Runtime Evironment library

I couldn't reproduce the “Unexpected byte range values defining scope of signed data” error message with the first example document, Foxit "merely" complained that the signature was invalid. Which it indeed is because you forgot to base64-decode the signature string before injecting it into the PDF - PDF requires the embedded signature containers in DER format.

The second example document was shared in a comment:

Now I don't get the error about the byte range anymore but I get new errors: "The document has been altered or corrupted since the Signature was applied." and "The Signer's identity is invalid because it has expired or is not yet valid." and "The signature includes an embedded timestamp but it could not be verified." Not sure if I'm doing it correctly now. This is the new file: https://drive.google.com/file/d/1vsa7thwCsi04r68cdcIsfJG7cT2__-d9/view?usp=sharing

Indeed, the signature container now is injected in DER format, so Foxit Reader can validate it. Concerning the new error messages:

"The document has been altered or corrupted since the Signature was applied." - this indicates here that there is some digest value mismatch.

Calculating and extracting the digest values in question shows that the SHA256 digest value of the signed byte ranges of the document is

In your example PDF the name of the signature field consists of 10 bytes, 9 bytes with value 0x00 and one byte with value 0x01. Apparently Adobe Reader does not like that field name.

After some experiments it looks like Adobe Reader does not like a field name starting with a 0x00 byte.

Maybe it contains some code that determines string lengths in a c'ish manner and interprets a 0x00 as end-of-string. A field name with a leading 0x00 byte, therefore, is interpreted as empty string, a field name not accepted by Adobe Reader either.

Thus, please use a signature field name made of (in particular starting with) some meaningful characters. As validators usually display the name of the signature field, this is a good idea anyways.

In terms of lowlevel PDF objects:

The signature field object looks like this:

So I figured it out.

Can I achieve my goal without having to manually upload a p12/pfx file, is it even possible?

Yes, it is. (See below on what needs to be changed.)

Is the server-side implementation of the deferred signature correct, do I need something else?

Yes, the code above is fine.

Is the pdf manipulation in javascript correct?

Also fine.

Can I transform the native CrytpoKey to forge or pkijs?

Yes, see below.

What is wrong with the last signature?

@mkl answered it in a comment, thank you.

FortifyApp has a CMS demo now. Although it didn't work with the version I was using, it works with version 1.3.4.

So I went with the pki.js implementation. The code changes need for the signing to be successful are the following:

1. Export the certificate: