Skip to main content
December 15, 2025
解決済み

Error during signature verification. Signature contains incorrect, unrecogniz.. (Byte range invalid)

  • December 15, 2025
  • 返信数 1.
  • 326 ビュー

Hi everyone,

I am trying to make an electroninc signing solution for flutter (as there are not many options available and I want to avoid API with third parties), that sign documents  in PAdES LTA quality.
While the DSS validator (https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/validation) and others say my documents signatures are valid (appart of the fact my certificate is DEMO), Adobe Reader keeps complaining about Byte range being invalid. (It also asks me if I want to save changes to the document when I am closing even without me making any changes at all - just checking it - and then errors out with 26 when I press yes).
I have checked the offsets and they seem to correctly point at the < and >+1 of the objects contents and the hashes seem to match.
That makes me think maybe Acrobat Reader is correcting some mistake I have made in the pdf and then revalidating with a new byte range?
Could someone point me in the right direction please?
Many thanks

解決に役立った回答 just_0161

Hi,

thanks for the reply.
I have just managed to solve it - the only issue was that the cross-reference stream's /W contained hardcoded value of 10, which was making the acrobat "repair" the file as it is probably too high (although the /Lenght was correct for the 10). 
I have started using real values for the /W (now calculated from contents - usually set to 1 or 2) and everything is now valid.

 

For anyone encountering issues with byte range invalid errors I recommend using "qpdf --check".

返信数 1

Souvik Sadhu
Community Manager
Community Manager
December 22, 2025

Hi @just_0161,

 

Hope you are doing well. Thanks for writing in!

 

All the comments below are based strictly on the file you attached here: 

You are on the right track, and your suspicion is very close to the actual root cause. What you are seeing is a well-known Acrobat-specific validation behavior that is stricter than DSS and most ETSI validators.

 

Acrobat requires that the ByteRange:

  • Covers everything except the signature contents

  • Excludes:

    • The < and > of /Contents

    • Exactly the correct number of hex characters

  • Does not include:

    • Trailing whitespace added by incremental updates

    • Cross-reference fixes

    • Repaired offsets

Many custom signers calculate ByteRange on the raw file bytes, but Acrobat recalculates using its parsed object model. More info here: https://adobe.ly/44Alb2Y

 

For PAdES signatures, Acrobat requires:

  • Signature added as a true incremental update

  • No modification of:

    • Previous xref table

    • Existing objects

  • A new xref section only

If your Flutter signer:

  • Rewrites the xref

  • Normalizes line endings

  • Reorders objects

  • Rewrites streams

Then Acrobat detects the file as modified after signing, which explains the "Error 26 on save."

 

The ETSI PAdES standard (EN 319 142) that Acrobat implements references the correct creation of the signature, including byte range and how signatures must be embedded and validated in a PDF document: https://adobe.ly/44ErbHQ

This standard describes how PAdES signatures must be embedded and validated — including the requirement that the cryptographic hash covers the correct byte ranges and that the signature container meets precise structural expectations.

 

Hope I was able to clarify your question.


Regards,
Souvik.

just_0161作成者解決!
December 27, 2025

Hi,

thanks for the reply.
I have just managed to solve it - the only issue was that the cross-reference stream's /W contained hardcoded value of 10, which was making the acrobat "repair" the file as it is probably too high (although the /Lenght was correct for the 10). 
I have started using real values for the /W (now calculated from contents - usually set to 1 or 2) and everything is now valid.

 

For anyone encountering issues with byte range invalid errors I recommend using "qpdf --check".