Why Your Digital Signature Is Not Working: Causes and Fixes

When a digital signature is not working, the cause almost always falls into one of five buckets: the signer's certificate has expired, been revoked, or is not trusted by your software; the document was changed after signing; your viewer is missing the root or intermediate certificates needed to build a trust chain; the timestamp or validation data in the file is incomplete; or the signing platform itself errored before the signature was applied. The fastest fix is to match your symptom—a red X, a yellow warning, an "invalid" banner, or a signing flow that fails—to the right cause. This guide covers triage, the common root causes, a step-by-step diagnosis, and prevention.

One clarification that matters here: a digital signature is a cryptographic, certificate-based mechanism that seals a document and proves integrity and signer identity, while an electronic signature is the broader legal concept of capturing intent to sign (a typed name, a click-to-sign button, a drawn scribble). If you are unsure which your workflow uses, see our guide on digital signature vs. electronic signature. Most "not working" validation complaints involve digital (certificate-based) signatures, so that is the focus below.

Quick Triage: Match Your Symptom First

Before changing any settings, identify exactly what "not working" looks like for you—different symptoms point to very different root causes. Run through this checklist and note which line matches your situation:

Red X or "Signature INVALID" banner in a PDF viewer — usually a certificate problem or a document modified after signing.
Yellow warning triangle or "validity unknown" — usually a missing root/intermediate certificate, no revocation data, or a timestamp issue.
"The digital signature on this message can't be verified" in email — usually a missing certificate chain, an expired S/MIME certificate, or content altered in transit. We cover this specific error in a dedicated guide.
You cannot complete signing at all (button greyed out, error during signing, loop back to login) — usually a platform-side, permission, or browser issue rather than a cryptographic one.
Signature shows valid on one computer but invalid on another — almost always a trust-store or viewer-configuration difference between the two machines.
Signature was valid before, then "broke" later — typically certificate expiry, a missing long-term validation (LTV) timestamp, or revocation information that aged out.

Once you know the symptom, the sections below map each one to its cause and fix.

Common Causes and How to Fix Each One

Expired, Revoked, or Untrusted Certificates

Every digital signature relies on a certificate issued to the signer, and yes, digital certificates do expire. When one expires, many viewers report the signature as invalid or unknown—unless the signature carries a trusted timestamp proving it was applied while the certificate was still valid.

A certificate can also be revoked before expiry (for example, if a private key was compromised or an employee left). Viewers check revocation via CRL or OCSP; if the certificate is revoked, or the viewer cannot reach the revocation service and treats that as a failure, validation breaks.

Finally, the certificate may be perfectly valid but simply not trusted on your machine—common with self-signed certificates or regional CAs missing from your viewer's default trust list.

Fixes:

Open the signature panel in your PDF viewer and inspect the certificate details: check the expiry date, revocation status, and issuer.
If the certificate expired but the signature has a valid timestamp, look for a viewer option to "validate at signing time" rather than at the current time.
If the CA is legitimate but untrusted locally, add the issuing CA's root certificate to your trusted identities (in Adobe Acrobat: the certificate's "Add to Trusted Certificates" option). Only trust roots you can independently verify.
If you are the signer and your certificate expired or was revoked, obtain a new certificate from your CA or signing platform and re-sign.

The Document Was Modified After Signing

A digital signature cryptographically seals the exact bytes of the document at signing time. Change anything afterward—even metadata, a form field, or an appended page—and the seal breaks. This is by design: it is what makes signed documents tamper-evident. The catch is that some post-signing changes (like incremental multi-party signatures) are legitimate, while others invalidate earlier signatures.

Fixes:

Compare the signed version against the original if you have it. Viewers like Acrobat can show "View Signed Version" to reveal what the document looked like at signing time.
Common culprits: someone flattened or re-printed the PDF, added a watermark, filled in a form field that was not designated as fillable-after-signing, or merged the file with another document.
If the change was accidental, go back to the untampered copy and route it for signature again.
For legitimate post-signing edits, use a workflow that supports sequential signatures rather than editing a signed file. Our article on whether a signed document can be modified after signing explains what is and is not allowed.

Missing Root or Intermediate Certificates

Validation works by building a chain from the signer's certificate up through intermediate CAs to a root CA your software already trusts. If the signed file does not embed the intermediate certificates, and your viewer cannot fetch them, the chain cannot be built and the signature shows as "unknown" or invalid. This is one of the most common reasons a signature validates on the sender's machine but fails on the recipient's.

Fixes:

Download the missing intermediate/root certificates directly from the issuing CA's official website and install them into your viewer's certificate store.
If you are the sender, re-export the signed document with the full certificate chain embedded (most professional signing platforms do this automatically; ad-hoc desktop signing often does not).
In enterprise environments, ask your IT team to push the required root certificates via group policy or MDM so every recipient's machine trusts the same CAs.

Viewer and Software Limitations

Not every application that displays a signed PDF can validate a digital signature. Browser previews (Chrome, Edge, Safari), many mobile viewers, and lightweight PDF tools often show no signature status at all—or misreport it. The signature itself may be fine; the tool simply cannot check it.

Fixes:

Open the document in a full-featured validator such as Adobe Acrobat Reader (desktop) before concluding anything is broken.
If you received the file by email, download it first rather than viewing it in the mail client's preview pane.
Standardize on one validation tool across your team so results are consistent, and document the steps in your digital signature verification procedure.

Timestamp and Long-Term Validation (LTV) Issues

A signature that validates today can fail years from now if it lacks long-term validation data. LTV embeds the timestamp, revocation responses, and full certificate chain into the file at signing time, so it can be verified even after certificates expire or revocation services go offline. Without LTV, old signatures frequently turn "invalid" purely because the supporting evidence aged out.

Fixes:

For documents that must remain verifiable for years (contracts, regulatory filings), use a signing platform that adds trusted timestamps and LTV data by default.
If you receive an older signed file that no longer validates, check whether the viewer offers "validate at signing time" using the embedded timestamp.

Platform-Side Signing Errors

If signers cannot complete the signing action at all—errors mid-flow, a page that reloads, a signature that never lands on the document—the cause is usually operational rather than cryptographic: expired signing links, blocked cookies, an outdated browser, a signer email mismatch, or a temporary provider-side service issue.

Fixes:

Retry in an up-to-date browser with cookies and JavaScript enabled, or switch from mobile to desktop.
Confirm the signing link has not expired and was sent to the correct email address; ask the sender to re-issue the request if needed.
Check the provider's status page, and if the error persists, capture the exact error message and contact the platform's support team.

Step-by-Step Diagnosis Workflow

When you are staring at a failed signature and are not sure which cause applies, work through these steps in order:

Read the exact error message. "Invalid," "unknown," "revoked," and "cannot be verified" are different diagnoses, not synonyms.
Reproduce in a full validator. Open the file in desktop Acrobat Reader (or your platform's verification tool) and check the signature panel.
Check the certificate. Note the expiry date, issuer, and revocation status—this single step resolves most cases.
Check for document modifications. Use "View Signed Version" or compare hashes against the original file.
Check the trust chain. Confirm the issuing CA's root and intermediates are present and trusted.
Check timestamps/LTV. For older documents, verify whether long-term validation data is embedded.
Test on a second device. If it validates elsewhere, the problem is local configuration, not the document.
Escalate with evidence. If nothing resolves it, send the sender (or platform support) the exact error text, certificate details, and file hash.

For a broader walkthrough of what "good" verification looks like, see our guide on why a digital signature shows as invalid.

How to Prevent Signature Failures

Most signature failures are preventable on the sending side:

Use a managed platform rather than ad-hoc desktop signing. Platforms embed the full certificate chain, timestamps, and LTV data automatically—the three things behind most recipient-side failures.
Renew signer certificates before expiry and keep an inventory of who holds which certificate.
Lock the document before signing. No post-signing edits, merges, or re-prints; route changes through a new signing round.
Test with a recipient on a different machine before sending high-stakes documents widely.
Standardize validation tools across your team, so "it looks broken on my screen" becomes a diagnosis, not a panic.

When to Switch Tools

If you keep hitting the same failure classes—recipients cannot validate your signatures, certificates are unmanaged, there is no timestamping or audit trail—the tool itself is the bottleneck. A modern e-signature platform handles certificate issuance, chain embedding, timestamping, and validation evidence as part of the signing flow, removing most of the causes in this article. When evaluating alternatives, look for automatic LTV support and an audit trail you can hand to a counterparty when they ask "is this signature real?"

Troubleshoot Less with Nota Sign

Nota Sign is FaDaDa's global e-signature platform, built so that signature failures like the ones above are the exception, not the routine. FaDaDa is IDC-ranked #1 in China's e-signature software market for consecutive years, and Nota Sign extends that infrastructure globally with legal coverage across 100+ countries and regions. For teams working across Asia-Pacific, it offers deep regional compliance support—including iAM Smart in Hong Kong, Singpass in Singapore, SES/AES/QES signature levels, and regional data centers—alongside the timestamping, certificate management, and audit trails that keep signed documents verifiable long after signing day.

Pricing is positioned to be practical: there are no per-seat fees, which keeps costs friendly for small teams and small businesses, while mid-market and enterprise buyers can get tailored plans matched to their volume and compliance needs.

If broken signatures are slowing down your deals, talk to the Nota Sign team about a signing workflow your recipients can actually verify.