Certificate errors
When using a certificate through either the Digitally Sign or Certify (Visible Signature) options, multiple errors occur that prevent the signature from being successfully applied, even after completing the signing process. In some instances, the signature appears to process and load but then disappears as if it was never applied. Other times, error messages are displayed saying that the document is open by another user (when it is not), the byte range is invalid, or there is an error displaying the signature. In some cases where an error says the signature cannot be displayed, closing and reopening the PDF may show the signature (sometimes). The issue is intermittent but frequent. It is often necessary to repeat the signing process multiple times before the signature is successfully applied. In some cases, it would take at least five attempts before it would complete successfully.
Suzie Dabbain
shared this idea
-
Eric H commented
We ran into this same issue in our environment, Here is a summary of what I have found.
When signing a PDF with a digital certificate on a network share, Acrobat opens the file with exclusive access (ShareMode: None) to write the signature. If any other process holds a handle on the file at that instant, the open fails with a SHARING VIOLATION. Rather than retrying or failing loudly, Acrobat often silently drops the signature (or produces an invalid byte range). Because it depends on exact timing, it's intermittent - it can take multiple attempts before a signature persists.
Reproducible evidence (Process Monitor): Signing a dummy pdf file on a network share, Acrobat requests Generic Read/Write, ShareMode: None and gets SHARING VIOLATION while an on-access scanning process holds a handle; Acrobat then falls back to a Generic Read, ShareMode: Read open, which cannot correctly finalize the signature. This repeats across multiple traces. The interfering handle came from endpoint security software (in our case a DLP agent and, at times, the Microsoft Defender for Endpoint sensor). It usually only reproduced on share drives in our environment because the DLP agent which was our main culprit didn't scan local files. Either way, the root cause is Acrobat's intolerance to any concurrent handle at the commit step, not the specific agent.
Environment: Windows, PDF stored on an SMB network share. (Note to others reading: whether this reproduces for you depends on what on-access scanning tools you run and where they scan)
This NEEDS a fix from Adobe/Acrobat: There is no Acrobat setting that resolves this; other PDF tools do not fail the same way under the same conditions. Suggested robustness improvements:
- Retry the exclusive open with a short backoff on a transient SHARING VIOLATION (the conflicting handle is typically released within a fraction of a second).
- Fail loudly with a clear, actionable error instead of silently dropping the signature. This would be better, but not a full solution, I would prefer a signature to actually save correctly every time instead of error out.
- Use an atomic write (write to a temp file, then swap) so signing doesn't depend on an uninterrupted exclusive handle on the live file.I have Procmon traces (failures and success) that I have attached so you can see that whenever adobe fails to request its ShareMode: None with a SHARING VIOLATION, that is when the PDF Fails to save the signature. You'll notice that in the procmon trace for the success, the scanning tool actually has a SHARING VIOLATION once, but that does not affect Acrobat saving the file, so it is irrelevant, it just shows that in this case, Acrobat won the race condition.
