The timestamp and the claimed signing time disagree. Which one counts?

The timestamp. Signing time is a self-declared attribute written by the signer's own machine, and nothing stops it being wrong, misconfigured or edited. A timestamp token comes from a trusted authority. When the two disagree, the timestamp is the evidence and the claimed time is a hint.

Revocation data couldn't be fetched, or it's stale. Does that fail the check?

That's an incomplete answer rather than a failure. The validator asks the CA's OCSP responder or downloads a CRL, and sometimes that endpoint is offline, throttled or simply slow. You get an indeterminate result instead of a clean pass, which is the honest outcome. Try again later. On LT and LTA signatures the revocation data is embedded in the file, so validation runs offline and this never comes up.

The signature is valid but not qualified. What's missing?

One of two things. Either the signing certificate came from a provider that isn't a qualified trust service provider on the EU Trusted List, or it was issued as an ordinary certificate rather than a qualified one. Both give you a technically sound signature that doesn't reach QES status. Whether that matters depends entirely on the transaction. eIDAS 2.0 and e-signatures covers where the bar is moving.

Another tool said valid, this one says invalid. Who's right?

Both can be, because they're often answering different questions. Adobe Acrobat trusts its own certificate store, which is not the EU Trusted List, so a signature can be trusted there and unqualified here. Some tools also check integrity only and skip revocation altogether. Read the detailed report instead of the headline verdict, and compare check by check: integrity, chain, revocation, timestamp. ETSI EN 319 102-1 defines the procedure, including a third outcome plenty of tools hide: indeterminate, meaning the evidence was incomplete rather than the signature being bad. A tool that collapses that into a red cross will disagree with one that reports it honestly.

Can I verify an electronic seal instead of a signature?

Yes. A qualified electronic seal runs through the same validation procedure and the report reads the same way. The difference is whose it is: a seal belongs to an organisation, so the certificate names a legal entity rather than a person. Sealed invoices and registry extracts check out here without any special handling.

eIDAS signature validation

Verify a qualified electronic signature under eIDAS

Upload a signed file and get a verdict in seconds: integrity, certificate chain, revocation state, timestamps, and whether the signature actually qualifies under Regulation (EU) 910/2014. PAdES, XAdES, CAdES and ASiC files all go through the same form, and it's free.

Verify a signed file

VERIFY A SIGNATURE

Verify an Electronic Signature

Upload any signed file, whether PDF, XML, .p7m, .p7s or an ASiC container, and validate its signatures against EU DSS verification standards.

Document validation is free

What the signature check includes

PAdES, XAdES, CAdES and ASiC validation
Certificate chain and revocation checks
Detailed report ready in seconds
Your document is never stored

Validate in Chaindoc

Two facts people tend to mix up. First: the file you upload is never stored. Second: the verification report is stored, privately, for 7 days and then deleted. After that only a minimal record (result, signature count, date) stays in your account.

Which format do you have

Work out the format of your signature

Four formats cover almost everything you'll meet in the EU, and the form above takes all of them. If you're not sure which one you're holding, just upload the file and let the detector sort it out. When you want the format-specific detail, these pages go deeper.

PDF files: PAdES

A signature embedded inside the PDF itself, profiled by ETSI EN 319 142. This is what Adobe Acrobat, DocuSign and most EU government portals produce. Nothing travels separately, so the file validates on its own. Profile detail lives on PDF signature verification.

XML files: XAdES

XML signatures under ETSI EN 319 132, which carry EU e-invoicing (FatturaPA, Facturae) and most public-sector filings. Extensions are .xml and .xsig. Watch for the detached variant, where the signature and the signed data live in two separate files. See XAdES verification.

.p7m and .p7s files: CAdES

Binary CMS signatures from ETSI EN 319 122. Italy's firma digitale uses .p7m, which wraps the document inside the signature. A .p7s is the detached cousin and needs the original file alongside it. More on CAdES verification.

.asice and .asics containers: ASiC

A ZIP package described by ETSI EN 319 162 that carries documents and signatures together. ASiC-S holds a single data object; ASiC-E holds several plus a manifest. The .scs and .sce extensions mean the same two things. Estonia's .bdoc is an ASiC-E container under an older name: rename it to .asice or .zip if the upload refuses it. See ASiC verification.

Baseline levels

What B, T, LT and LTA actually mean

Every AdES format uses the same four baseline levels. You'll see them written as XAdES B-B, B-T, B-LT and B-LTA, or as PAdES-BASELINE-B through PAdES-BASELINE-LTA, or the CAdES equivalents. Same ladder, different wrapper. The validation procedure behind all of them is ETSI EN 319 102-1, and the level you need depends on how long the signature has to stay provable, not on how important the document feels.

B: the signature itself

Signer's certificate, the signed attributes, and the cryptographic binding to the document. That's enough to be an advanced electronic signature under eIDAS. What B can't tell you is when the signing happened, which turns out to matter more often than teams expect.

T: a trusted timestamp

Adds a timestamp token from a trusted authority, proving the signature existed before a specific moment. If a filing deadline or a contract date is ever disputed, this is the level that settles it. Without T you're trusting the clock on somebody else's laptop.

LT: long-term validation data

Bundles the certificate chain and the revocation responses (CRL or OCSP) into the file itself. The signature then validates on its own years later, even after the issuing CA has gone offline or stopped publishing revocation data. This is the level most archives should be asking for.

LTA: archival timestamps

Wraps the whole thing in an archive timestamp that gets refreshed over time, so the signature stays verifiable for decades as hash algorithms age out. Honestly overkill for an NDA. Correct for a mortgage, a medical record, or anything with a statutory retention period.

Trust and qualification

What makes a signature qualified

Valid and qualified are two different verdicts, and confusing them is the most common mistake in a compliance review. A signature can be cryptographically perfect and still not be a QES. Here's what separates them, and who decides.

Qualified is a legal status, not a quality rating

Under eIDAS, a qualified electronic signature needs a qualified certificate plus a qualified signature creation device. Only a QES gets automatic legal equivalence to a handwritten signature in every member state. An advanced signature is still admissible evidence, it just doesn't carry that automatic equivalence.

The EU Trusted List settles it

Whether a certificate is qualified isn't a judgement call. Member states publish national Trusted Lists under ETSI TS 119 612, aggregated into the EU Trusted List (EUTL). Chaindoc checks signer certificates against the EUTL, so the qualified verdict is a lookup rather than an opinion.

Qualified trust service providers

A qualified trust service provider is a certificate issuer that a national supervisory body has audited and admitted to the Trusted List. Certificates from a QTSP carry qualified status. A perfectly reputable commercial CA that isn't on the list will produce valid signatures that are not qualified, which surprises people more than it should.

Electronic seals belong to organisations

An electronic seal proves origin and integrity for a legal entity rather than personal intent for a human being. Invoices, registry extracts and automated filings usually carry a seal, not a signature. Qualified seals climb the same B to LTA ladder and validate here the same way.

eIDAS-ready signing

Signatures that hold up under eIDAS

Chaindoc pairs every e-signature with a tamper-evident blockchain trail and checks it against the same EU DSS rules this tool runs. Sign documents online free — and when a regulator asks how you know, the trail answers.

Get started free See pricing

After the check

The report came back. Now what?

A verdict is only useful if you know what to do with it. These are the four outcomes you'll actually see, and how each one usually gets handled.

Valid and qualified

You're done. The report records the signer, the certificate, the timestamp and the trust anchor as they stood when you checked, and it stays in your account for 7 days. If the signature is only B or T level, save your own copy before then, because the revocation data it relied on won't stay reachable forever.

Valid but not qualified

Common, and usually fine. The signature holds up cryptographically; the issuer just isn't on the Trusted List. Whether that's acceptable is a policy question rather than a technical one. The guide to qualified electronic signatures walks through where an advanced signature is enough and where a QES is required.

Invalid: integrity failed

The document changed after signing, even by one byte. Flattening, re-saving or an OCR pass will do it, and none of those are malicious. Go back to the sender and ask for the original signed file rather than a copy that has been through a document management system.

Invalid: trust or revocation failed

The cryptography is fine, but the chain doesn't reach a trusted root or a certificate was revoked. Neither is automatically fatal. The FAQ below covers how to read each case, and compliance across eIDAS, GDPR and NIST covers what you should be documenting. Checking at volume? See pricing and the API.

FAQ

When validation fails, and what it means

The questions that come up when a report doesn't say what you expected. More on our support page.

It means the validator followed the certificate up to its issuer and didn't find a root it recognises. Usually that's an internal or national CA that isn't on the EU Trusted List, not an attack. The signature can still be cryptographically sound. Look at who issued the certificate, then decide whether your policy accepts that issuer. If it's your own internal PKI, custom trust anchors are the fix rather than a workaround.

Almost always because the document changed after signing. A signature commits to a digest of specific bytes, so any edit breaks it, including edits that feel harmless: re-saving through a different PDF writer, flattening annotations, running OCR, or letting a mail gateway rewrite the attachment. Nothing malicious has to have happened. One PDF-specific case is worth knowing before you accuse anyone: a PDF can carry later revisions appended to it, so a signature may legitimately cover an earlier revision rather than the version you're looking at now. Check which revision it covers. Otherwise ask the sender for the file exactly as it left their signing tool, not a copy that has been through a document management system.

Two usual causes. Either the signature is detached and lives in a separate file, so the one you uploaded genuinely carries no signature. Or what's in the document is a picture of a signature, a scan or a drawn squiggle, which has no cryptography behind it and nothing to validate.

Because detached signatures don't contain the data they sign. A .p7s file, and some .xml and .xsig files, hold the signer's certificate and a digest, nothing else. Without the original there's nothing to re-hash and compare against. Upload both the signature file and the exact document it was signed over. Exact is the operative word: a re-exported or re-saved version won't match.

No, and this one trips people up constantly. What matters is whether the certificate was valid at the moment of signing, not whether it's valid today. That's precisely what a trusted timestamp is for: it proves the signature existed while the certificate was still live. Without a timestamp, on a plain B-level signature, you can't prove when it was signed, and an expired certificate does become a real problem.

Guides and resources

eIDAS and qualified signature guides

Where an advanced signature is enough, where a QES is required, and what eIDAS 2.0 changes for teams collecting signatures in the EU.

Compliance analyst checking the qualified certificate behind a signature against the EU Trusted List on a monitor

July 16, 2026