Digital Documents And Trust
Digital documents often travel as PDFs, then get signed so recipients can check integrity and signer identity. In Europe, eIDAS sets the legal framework for electronic identification and trust services, including qualified electronic signatures and qualified trust services. A signed PDF is not automatically “valid” just because it looks official; validation depends on cryptographic evidence inside the file and on trust settings in the validator you use.
A practical example: a clinic sends you a PDF with a visible signature panel. You can still open the document in a viewer, but the viewer’s “valid” label depends on whether it can build a certificate chain, fetch revocation status, and confirm the signature’s timestamp. If the signature was created with a certificate that later got revoked, the outcome can change depending on whether the signature includes a trusted timestamp and how the validator interprets it.
Another example: a public authority issues a signed PDF for a procedure. The signature may be embedded as a CMS/PKCS#7 object, with a certificate chain and sometimes revocation data. Validation tools differ in how they interpret PDF signature standards and how they handle missing intermediate certificates, which is why two people can see different results from the same file.
Common Validation Pain Points
People often treat “signature present” as “signature verified.” In reality, verification checks multiple layers: the PDF signature’s cryptographic correctness, the certificate chain to a trusted root, the certificate’s validity period, and revocation or status information. If any layer fails, a validator may show “unknown,” “invalid,” or “not validated,” even when the signature panel looks normal.
Another frequent misunderstanding is mixing legal categories with technical outcomes. eIDAS distinguishes between electronic signatures, advanced electronic signatures, and qualified electronic signatures, and the legal effect depends on the category and the trust service provider’s status. A PDF signature can be technically valid while still not meeting the requirements for a qualified signature, which matters when a contract or medical workflow expects a specific legal level.
PDF signatures also depend on how the signature is embedded. Some PDFs use PAdES profiles (PDF Advanced Electronic Signatures), which define how long-term validation data like timestamps and revocation information can be stored. If a document uses a basic profile without long-term validation data, validation may fail later when revocation endpoints are unreachable or when the certificate expires.
Revocation checking causes many “it worked yesterday” cases. Validators may query OCSP or CRL endpoints, and network restrictions, proxy settings, or blocked URLs can prevent status retrieval. Even when the signature is cryptographically correct, the validator can mark it as “not validated” because it could not confirm status at validation time.
Certificate chain building is another dependency. If the PDF includes only the signer certificate and omits intermediates, some validators can still fetch missing certificates, while others cannot. I once saw a validation failure tied to a missing intermediate certificate in the file, and the same PDF validated after exporting the full chain from the issuing system.
How To Validate A Signed PDF
Check The Signature Panel Details
Start with the signature panel in your PDF viewer, but treat it as a hint, not a verdict. Look for fields such as signer name, signing time, signature type (if shown), and the validation status label. Then open the “signature properties” or “show details” view to inspect the certificate chain and whether the validator performed revocation checks.
If your viewer shows only “valid” without explaining revocation or timestamp behavior, switch to a dedicated validator. For example, the European Commission’s eIDAS reference tools and common PAdES validation workflows often rely on explicit trust settings and status retrieval. A mild frustration: many viewers hide the underlying reason codes, so you end up guessing why a signature is “unknown.”
Verify Certificate Trust And Status
Validation requires a trust anchor: the root certificate of the trust service provider must be present in the validator’s trust store. Confirm that the validator recognizes the issuing CA and that the certificate chain builds successfully. Then check certificate validity dates and the signature’s signing time.
Revocation status is usually checked via OCSP or CRL. If the validator cannot reach the endpoints, it may mark the result as “not validated.” When the signature includes a trusted timestamp, validators can often treat the certificate status at the signing time as the relevant evidence, even if the certificate later expires or gets revoked.
As a concrete aside, I have seen different outcomes between validators when one tool cached OCSP responses and another tried to fetch fresh status. In one case, the OCSP responder URL returned an error during validation, and the signature remained cryptographically correct but could not be status-validated.
Confirm eIDAS Signature Category
Technical validity does not automatically mean the signature meets a qualified eIDAS requirement. To assess the category, look for indicators tied to qualified trust services, such as a qualified certificate and, in many workflows, a qualified trust service provider identifier. Some validators can display whether the signature is “qualified” or “meets advanced requirements,” but the exact wording depends on the tool.
If you need legal certainty for a specific process, ask the issuer for the signature profile and the trust service details, or validate using a tool that supports eIDAS-aware reporting. A document that is “valid” but not “qualified” can still be acceptable for many administrative tasks, yet it may fail a workflow that requires qualified signatures.
Use Long-Term Validation When Needed
Long-term validation matters when you must rely on a signature years later. PAdES long-term profiles store evidence such as timestamps and revocation data inside the PDF so validation does not depend on contacting OCSP/CRL endpoints at the future date. Without those stored evidences, validation can degrade after certificate expiry or when status services change.
When you receive a document for recordkeeping, check whether it includes a trusted timestamp and whether the signature profile supports long-term validation. If the signature uses a short-term profile, you may need to re-validate periodically or store the validation report alongside the document.
One practical method: export a validation report from your validator and keep it with the PDF. If you later need to prove the signature’s status, the report can show what the validator checked and when, though it does not replace the cryptographic evidence inside the file.
Case Examples For Real Scenarios
Clinic Referral PDF With “Unknown” Status
A patient receives a signed PDF referral on 2026-03-14. Their PDF viewer shows a signature panel, but the validation status reads “unknown.” The certificate details show the signer certificate is within its validity period, yet the viewer cannot fetch revocation status from the OCSP URL due to a corporate firewall rule.
The patient re-validates using a validator configured to use direct internet access. The signature verifies cryptographically, and revocation status is retrieved successfully, changing the result to “valid.” The patient saves the validation report for their records, because the next time they open the file, the same firewall rule might block status retrieval again.
Public Authority Document With Expired Certificate
A user receives a signed PDF notice from a public authority. The signature was created in 2024, and the signer certificate expires in 2025. In 2026, the user validates the PDF and sees “valid” because the signature includes a trusted timestamp and long-term validation evidence.
In a second attempt, the user tries to validate the same file with a tool that does not support long-term evidence extraction. That tool marks the signature as “not validated” because it cannot confirm status at the current time and does not interpret the stored timestamp evidence. The user learns to rely on a validator that understands the PDF signature profile used by the issuer.
Validation Checklist And Comparison
| Check | What You Look For | Why It Matters | Common Failure |
|---|---|---|---|
| Signature Integrity | Cryptographic check passes for the signed byte ranges | Detects tampering after signing | PDF modified after signing |
| Certificate Chain | Chain builds to a trusted root in the validator | Confirms the signer’s trust anchor | Missing intermediate certificates |
| Revocation Status | OCSP/CRL status retrieved or stored evidence used | Detects revoked certificates | Blocked OCSP/CRL endpoints |
| Timestamp Evidence | Trusted timestamp present for long-term validation | Supports validation after expiry | No long-term profile data |
| eIDAS Category | Qualified/advanced indicators match the workflow needs | Determines legal expectations | Valid but not qualified |
Step-by-step checklist you can apply to any signed PDF:
- Open the PDF and open signature properties, then record the signing time shown by the signature.
- Check whether the validator reports “valid” with revocation status confirmed, not just “signature present.”
- Inspect certificate chain details and confirm the issuing CA is recognized by your validator’s trust store.
- Look for timestamp evidence and whether the signature profile supports long-term validation.
- If the result is “unknown” or “not validated,” identify the reason code: missing chain, blocked OCSP/CRL, or unsupported profile.
- Save a validation report if you need audit-ready records for later review.
Common Mistakes That Break Trust
One mistake is re-saving or editing the PDF after receiving it. Some editors rewrite the file structure and can invalidate the signed byte ranges, turning a previously valid signature into an invalid one. If you must annotate, use a tool that preserves the original signed content and adds annotations without altering the signed ranges.
Another mistake is trusting a single viewer label. Different PDF viewers and validators interpret PAdES profiles differently, and some hide revocation or timestamp evidence. A signature that validates in one tool can show “unknown” in another when the second tool cannot fetch status or does not parse the stored evidence.
People also confuse “certificate expired” with “signature invalid.” A signature created while the certificate was valid can remain valid if the signature includes trusted timestamp evidence and the validator applies the correct long-term validation logic. If you see “expired” in the certificate details, check whether the validator still reports a valid signature outcome.
Finally, readers sometimes accept a document without checking the signature category when a workflow expects a qualified signature. If a clinic, insurer, or authority requires a qualified electronic signature under eIDAS, the validator should show that category or the issuer should provide the trust service details. When the category is unclear, ask for clarification rather than guessing.
FAQ
What Does A “Valid” PDF Signature Mean?
A “valid” result means the signature’s cryptographic checks pass and the validator can build a trust chain and interpret status evidence according to its configuration. If revocation status could not be checked, some tools still show “not validated” rather than “valid.”
Why Does The Same PDF Show Different Results?
Different validators use different trust stores, revocation-fetch behavior, and support for PAdES long-term evidence. Network restrictions can block OCSP/CRL calls, and missing intermediate certificates can prevent chain building.
Does eIDAS Apply To All PDF Signatures?
eIDAS provides the legal framework for electronic signatures and trust services in the EU, but a PDF signature can be technically valid without meeting the requirements for a qualified signature. The legal effect depends on the signature category and the trust service provider’s status.
What Is The Role Of A Timestamp?
A trusted timestamp links the signature to a time and supports long-term validation, especially when certificates expire later. Validators use timestamp evidence to decide which certificate status matters for the signature.
How Can I Validate Without Technical Expertise?
Use a validator that shows reason codes and certificate chain details, then follow the checklist: integrity, chain trust, revocation status or stored evidence, and timestamp presence. If the tool reports “unknown,” record the reason and ask the issuer for a re-issued file or validation details.
Author's Insight
PDF signatures rely on cryptography plus trust decisions made by the validator, so “looks signed” does not equal “validated.” eIDAS defines legal categories, while PAdES profiles define how evidence is stored for long-term checks, which explains why some files keep validating years later and others do not. Validation outcomes vary when revocation endpoints are unreachable or when the PDF lacks intermediate certificates. A practical approach is to treat the validation report as part of the document package, especially for records you may need to reference later.
Key Takeaways
- Validate the signature’s cryptographic integrity, certificate chain, and revocation or stored evidence, not just the visible signature panel.
- Use timestamp evidence and PAdES long-term profiles when you need future-proof validation.
- Check eIDAS signature category indicators when a workflow expects a qualified signature, since technical validity does not guarantee legal category.
- When validation shows “unknown” or “not validated,” identify the reason code and address it by switching validators, fixing trust settings, or requesting a re-issued document.
