eIDAS Signature Validator

How to verify an eIDAS signature

Checking a signed document means answering separate questions that are easy to run together. Has the document changed since it was signed? Who holds the key that signed it? Does anyone the EU recognises vouch for that key holder? A signature can pass the first and fail the others, and the result above is laid out so you can see which.

Verifying a PAdES, CAdES or JAdES signature online

Drop the file in the box above. The format is read from the file itself: a signed PDF is PAdES, a PKCS#7 or CMS file is CAdES and a JWS is JAdES. XML and ZIP files are recognised as XAdES and ASiC and reported as not yet validated. Each signature the tool reads gets its own result, with these parts.

1. Integrity. Whether the signature verifies over the signed bytes with the certificate embedded in it. In a PDF those are the bytes the signature's /ByteRange names, so a change to any of them fails this check.
2. Evaluated at. The moment the chain and qualification are judged at. A signature timestamp wins if it verifies against the signature and its authority is accepted, as the levels section below describes. Otherwise it uses the signing time the signer claims, a value the signer chooses. With no time it can read, it judges as of now and says so. For CAdES and JAdES the claim is the signing time attribute or the sigT header. For PAdES it is the signature dictionary's /M entry, where the PAdES baseline records it. A signing time inside the CMS is used only when /M is missing or unreadable. A baseline signature that carries one is reported, since the baseline says it shall not be present. In a PDF a document timestamp added after the signature also counts once it is accepted, and its time wins when it is earlier than an accepted signature timestamp's: it attests that the signature existed by then.
3. Certificate chain. Whether the signer's certificate builds a path to a root the verifier trusts. Many qualified providers' roots are not in that store, which is why qualification is a separate check.
4. Qualification. Whether the signer chains to a CA that the trusted list of its issuer's country granted qualified status at the time above. The next sections explain what that does and does not mean.

Click Load PAdES example to see all four on a known file. Its signature reads as integrity valid at level B, evaluated at the signer's claimed time, which the example carries in its /M entry. The example is a plain PDF signature rather than a PAdES baseline one, so level B here only means it carries no signature timestamp. The chain stops at UntrustedRoot and qualification is indeterminate, because the example signs with a certificate it issued to itself and that certificate names no country. The PDF is intact, but nothing says who signed it, which is what a signature someone calls valid can turn out to mean.

What levels B, T, LT and LTA mean

The ETSI baseline standards for PAdES, CAdES and JAdES each define four levels, in clause 6.1 of each. B-B covers the signature as created, with its signed attributes and some unsigned ones. B-T adds a trusted token proving the signature existed at a certain time, in practice an RFC 3161 timestamp. B-LT adds the material needed to validate the signature later, such as certificates and revocation data. B-LTA adds further timestamps so it can still be validated after that material expires or an algorithm weakens.

This tool reports B, T, LT and LTA for PAdES and CAdES. It reads T only for PAdES and CAdES: when the signature carries a signature timestamp inside it or, in a PDF, when an accepted document timestamp added after it covers it, which PAdES allows for B-T (ETSI EN 319 142-1 clause 6.3). Document timestamps are listed on their own under the signatures, with what each covers. For a PDF it also reads the Document Security Store, the file's own set of certificates, CRLs and OCSP responses. A signature at T whose file carries a store with certificates and revocation data reads LT, and LTA when a valid document timestamp covering it was made over such a store. The counts show what the store holds, not that it covers the signer's chain. The CRLs and OCSP responses in it, and in a CAdES signature's SignedData, are read for the revocation of the signer's certificate and the certificates above it: each is reported not revoked, revoked, on hold or not determined, and a revocation is named in the findings. The same data, with the data a timestamp carries itself, is read for each timestamp's authority and the certificates above it, at the current time: one that is revoked or on hold makes the timestamp refused. A timestamp whose authority has since expired or been revoked is judged again at the time a later accepted timestamp proves it existed (ETSI EN 319 102-1 clause 5.6): a document timestamp that covers it in a PDF, or in CAdES an archive timestamp whose hash index lists it. It is accepted then only if the file's revocation data shows its authority neither revoked nor on hold by that time; the report says when that happened. Nothing is fetched, so a file that leaves that data out is not caught, and the findings say the authority's revocation was not checked. A CAdES signature at T reads LT when its SignedData carries a CRL or an OCSP response, where the baseline puts them (ETSI EN 319 122-1 clause 6.3); CAdES LTA adds an archive timestamp, valid and made over a certificate and a revocation answer of the signature, which the report lists. LT and LTA are claimed only for a signature that verifies and whose time an accepted timestamp attests: one that reads T from a refused timestamp, or does not verify, stays T. JAdES always reads as B for now, because its timestamps are recognised and reported but not yet validated.

A signature timestamp is only used for the evaluation time once its authority is accepted today, or at the time a later accepted timestamp proves it existed, as above. Among other checks, the authority must chain either to a root the verifier trusts or to a qualified timestamp service on the trusted list of the country its certificate names, granted both today and when the token was made. An old timestamp whose authority certificate has since expired is refused, as is one that relies on a list entry since withdrawn. The time then falls back as described above while the level still reads T. A refused document timestamp gives no T at all, so a B-LTA PDF whose only timestamps come from an authority that has since expired reads B, with its store listed, until validation at the time its timestamps prove is built.

Why a signature can be valid but not qualified

Under eIDAS a qualified electronic signature is an advanced electronic signature created by a qualified electronic signature creation device and based on a qualified certificate for electronic signatures (Article 3(12)). It has the equivalent legal effect of a handwritten signature (Article 25(2)). A signature that is not qualified still counts: under Article 25(1) an electronic signature shall not be denied legal effect and admissibility as evidence solely because it does not meet the requirements for qualified electronic signatures.

What this tool checks is narrower than that definition. It asks whether the signer's certificate was an EU qualified certificate when it was used, following ETSI TS 119 615 clause 4.4.4 and the national trusted lists each Member State publishes under Article 22. The certificate's CA must hold granted qualified status on the list of the issuer's country, and the list must grant it for the right use: signatures, seals or website authentication. The list can also qualify some of a CA's certificates and not others. The certificate states for itself whether it is qualified (QcCompliance) and what for (QcType), and the tool reads all of these together. It does not check the signature creation device, so EU qualified here means a qualified certificate for the use the list and the certificate settle on, which the line under the answer names. A qualified certificate for signatures is necessary for a qualified electronic signature and not enough to prove one.

The status is judged at the evaluated time, so a signature made while its CA was qualified stays qualified after the CA is withdrawn, as long as the list still carries that CA's history. A provider removed from a list entirely takes its history with it and reads as not qualified. Without an accepted timestamp, the evaluated time is the signer's own claim or, failing that, now. The same question is then asked again as at the date the certificate was issued, and the answer stands only if both agree (ETSI TS 119 615 clause 4.4.4); otherwise it is indeterminate. A certificate issued while its CA was granted, but used after the CA was withdrawn, reads indeterminate for that reason.

The other answers mean something specific.

• Not qualified: the chain reaches no CA on the trusted list of the issuer's country, or it reaches one that did not hold granted status at that time or was granted only for other uses. A certificate from a company's own CA usually lands here, as does one signed before its CA was listed. So does a certificate the list marks NotQualified and, in most cases, one that does not declare itself qualified (no QcCompliance).
• Indeterminate: no list could decide. The issuer's certificate names no single country, names one with no list on the EU list of trusted lists or names one whose list failed to load. A CA whose status at that time came from the regime before eIDAS, such as accredited or under supervision, also lands here, since the tool does not map those onto qualified. A certificate whose QcType names more than one use can land here too, as can one the list's entries disagree about or qualify in ways ETSI TS 119 615 treats as inconsistent.
• Not evaluated: nothing was decided, and the line under it says why. A detached signature uploaded without the content it signs gets this answer, as does a signature without its certificate. Retrying will not change either. It also appears while the trusted lists are still loading, when trying again shortly helps. If they could not be fetched, the next attempt comes with the daily refresh.

What this does not check

Revocation: the tool does not fetch OCSP or CRL responses. It reads only those the file carries, so a certificate whose revocation the file does not settle still shows a chain, and the report says it was not checked. ETSI TS 119 615 also repeats the qualification check at the date the certificate was issued, and this tool does not yet make that second check. The national trusted lists are fetched from the addresses the EU list of trusted lists gives, and the lists' own signatures are not yet verified. The result is informational. It is not a qualified validation service under eIDAS (Articles 33 and 40), and a decision that rests on a signature should use one.

Sources

• Regulation (EU) No 910/2014 (eIDAS), as amended, consolidated text of 18 October 2024: Articles 3, 22, 25, 32, 33 and 40
• ETSI EN 319 142-1 V1.2.1 (2024-01), PAdES baseline signatures, clauses 6.1 and 6.3
• ETSI EN 319 122-1 V1.3.1 (2023-06), CAdES baseline signatures, clause 6.1
• ETSI TS 119 182-1 V1.2.1 (2024-07), JAdES baseline signatures, clause 6.1
• ETSI TS 119 615 V1.4.1 (2026-05), procedures for using and interpreting national trusted lists
• RFC 3161, Time-Stamp Protocol