Why Can a Signed PDF Look Valid in One Viewer and Invalid in Another?
Five checks to distinguish changed content, certificate trust, and incomplete validation evidence
A signed PDF shows a valid signature in one reader and a warning in another. Before deciding that the signature is broken, check whether both readers opened the same file, checked the same signed revision, and used the same trust and validation settings.
A visible signature image, an embedded digital signature, and a signing provider’s audit trail are different kinds of evidence. Start by identifying which ones the workflow actually produced.
Separate three questions
- Did the signed content change? Check the cryptographic signature and the revision it covers.
- Does the validator trust the certificate? Check the certificate chain, trust policy, and relevant time.
- Is enough evidence available? Check timestamps, revocation information, and the validator’s supported features.
A reader may display the document without fully validating its signatures. Another may validate the signed bytes but lack a trusted certificate chain. Those outcomes need different responses.
Read the detailed result before reacting to the badge
| What the result says | What to investigate |
|---|---|
| No validation result | Does this viewer support and perform the required signature checks? |
| Certificate trust is not established | Can the validator build a chain to an authority trusted under the approved policy? |
| Validation is incomplete | Are timestamp or revocation evidence unavailable, or are required checks unsupported? |
| Integrity or document-change checks fail | Were signed bytes altered, or were later changes outside the permitted scope? |
The European Commission’s Digital Signature Service documentation distinguishes a failed result from an indeterminate one, where evidence is insufficient. Preserve the detailed report rather than reducing every warning to “invalid.”
1. Confirm that both viewers opened the same bytes
Retrieve the original signed PDF from the signing workflow and compare its checksum with each copy being investigated. Matching checksums establish that the files are identical; they do not themselves validate a signature.
Keep the provider-delivered PDF as a protected original with its version identifier and checksum. Optimization, flattening, combining files, adding a watermark, or regenerating a visually identical PDF can change signed content. Store previews and other transformed files separately, with a link to the original.
2. Check which revision was signed
A PDF signature covers specified byte ranges. A later signature or other update can be appended as a new revision. That means a signature can protect an earlier revision while the current file contains additional material.
Inspect the covered revision, later changes, and any applicable permissions. Adobe’s digital-signature guidance describes incremental saves and modification restrictions for certified documents. A valid check on an earlier revision is insufficient on its own to approve every later change.
3. Compare trust, time, and revocation settings
Record the viewer and version, trust configuration, validation time, certificate chain, timestamp result, and revocation result. One environment may trust a certificate authority that another does not. Network restrictions may also prevent retrieval of required validation evidence.
Adobe’s Acrobat validation guidance explains how to inspect signature and timestamp details. A claimed signing time is different from time supported by a trusted timestamp. Certificate expiry today also needs to be assessed in the context of the relevant time and available evidence.
Use the organization’s approved trust policy. Adding an unfamiliar certificate to a trusted list simply to remove a warning changes the test; it does not resolve the underlying trust question.
4. Keep the signing process evidence
Link the exact PDF version to the transaction identifier, intended documents, recipients, authentication method, signing sequence, provider status, and completion evidence. An embedded certificate may identify a provider or organization rather than independently establish the identity of every person who participated.
A drawn signature image is not a certificate-based digital signature. An electronic signing process may rely on provider records without producing the embedded signature a PDF validator expects. Likewise, a successful cryptographic check alone does not establish a person’s authority, consent, or the transaction’s legal effect.
5. Preserve evidence for later validation
For long-lived records, agree what certificate, timestamp, revocation, and validation evidence must remain available. Retain the validation report with its date, tool version, policy, covered revision, and outcome. A result is tied to that validation context.
The European Commission’s eSignature FAQ describes long-term validation material and archival protection. Confirm the required signature profile and preservation process with the responsible records and security owners.
What long-term validation adds
PAdES long-term profiles can retain certificate and revocation material, with additional timestamp protection for archival needs. This supports later validation when certificates expire or online evidence becomes unavailable; it does not guarantee that every future viewer will display the same result.
If a supported preservation process adds validation material or timestamps, retain the received original and track the augmented version and its validation history. Do not treat arbitrary post-signature editing as equivalent to controlled preservation.
Example: the same contract, two different results
Compare the files
A desktop reader reports a valid signature while a second viewer cannot establish certificate trust. Both copies match the checksum of the stored original, so a changed download is not the explanation.
Inspect the validation details
Both inspect the same signed revision. The first environment has the approved trust chain; the second lacks it. Check the certificate and evidence against the approved policy before changing trust settings.
Record the finding
Keep both reports and the configuration difference with the original PDF. If the signature mathematics, revision, or later changes fail a separate check, investigate that independently; resolving certificate trust cannot repair altered signed content.
Four checks for the document workflow
- Download the completed signed original through each delivery path and compare checksums.
- Generate a preview or watermark and confirm it cannot replace the stored signed original.
- Test missing trust and unavailable revocation evidence. Confirm that reports distinguish incomplete validation from a confirmed failure.
- Test a permitted later revision and an unauthorized change. Confirm that the chosen validator reports their different effects.
How FormKiQ supports signed-document preservation
FormKiQ’s eSignature Integration connects DocuSign signing workflows and returned documents to governed records. Contract Management and Records Management provide the surrounding business context.
Configure original-file preservation, completion handling, evidence links, and access controls for the workflow. Include the selected PDF validator and long-term preservation requirements in that design; an eSignature integration alone does not establish that every viewer will validate the output identically.
Talk to FormKiQ about preserving signed originals and their execution and validation evidence.