Verify a qualified electronic signature under eIDAS
Verify an Electronic Signature.
Chaindoc runs eIDAS signature verification on any file you upload: integrity, certificate chain, revocation, timestamps, and QES validation. One eIDAS compliance check covers PAdES XAdES CAdES ASiC files, 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
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.
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.
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 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.
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.
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.
What B, T, LT and LTA actually mean
The same ladder in every AdES format: XAdES B-B to B-LTA, PAdES-BASELINE-B to LTA, and the CAdES equivalents. One procedure covers them all, ETSI EN 319 102-1. The level you need depends on how long the signature must stay provable.
B: the signature itself
Certificate, signed attributes, cryptographic binding: an advanced electronic signature under eIDAS, with no proof of when it was signed.
T: a trusted timestamp
A trusted authority's timestamp proves the signature existed before a given moment. 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, so it still validates once the issuing CA goes offline.
LTA: archival timestamps
An archive timestamp, refreshed over time, so the signature survives ageing hash algorithms. Overkill for an NDA, right for a statutory retention period.
The certificate expires. The evidence shouldn't
Chaindoc pairs every signature it creates with a tamper-evident blockchain trail, so what you can still prove years from now doesn't rest on a certificate that has since lapsed.
Sign a documentWhat 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.
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.
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.
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.
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.
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.
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 at the check, and keeps them for 7 days. If the signature is only B or T, save a copy before then: the revocation data behind it won't stay reachable.
Valid but not qualified
Common, and usually fine. The signature holds cryptographically; the issuer just isn't on the Trusted List. That's a policy call, not a technical one. The guide to qualified electronic signatures says when an advanced signature is enough and when you need a QES.
Invalid: integrity failed
The document changed after signing, even by one byte. Flattening, re-saving or an OCR pass does it, none of them malicious. Ask the sender for the original signed file, not a copy that went 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 fatal by itself. The FAQ below reads each case; compliance across eIDAS, GDPR and NIST covers what to document. Checking at volume? See pricing and the API.
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.
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.
