How Do I Verify Someone's Digital Signature Is Authentic?

July 12, 2026 ·Gustav Poola ·

signature-verificationadeseidasetsi-319-102trusted-listcertificate-validationrevocationocspcrlauthentication

Through a structured five-stage validation chain defined by ETSI EN 319 102-1 — confirm the signature matches the document hash, resolve the signing certificate back to a trusted root, validate the certificate was not revoked at the signing moment, check the cryptographic algorithm policy was acceptable at the signing moment, and verify the signing time itself. The trust roots resolve against the EU Trusted List under eIDAS Article 22. Each stage produces a distinct verification result; a failure at any stage tells the verifier what specifically broke.

How Do I Verify Someone's Digital Signature Is Authentic?

There is a moment in every signature integration where the engineering team realises the lawyer is asking a different question than they thought. A Frankfurt-based logistics integrator we worked with last quarter walked into this moment: its legal counsel had read the audit clause in BaFin's letter on cross-border supplier signatures, found the phrase "ensure validation conforms to Article 32 of the Regulation", and asked what the integrator's existing verification check actually validated. The engineer reached for the hash-comparison code in the integration and started to explain it. Two minutes later it was clear the explanation was not landing — and it took a follow-up with the integrator's QTSP vendor to confirm that the implementation only ran two of the five checks the Regulation requires. The other three were the ones the audit would actually turn on. The verification framing here pairs with our earlier post on signature terminology (definitions) and our long-term validity walkthrough (the same check at month 48 instead of month 1).

What does "verifying a digital signature" actually require?

A structured procedure that runs five distinct checks against the signature, the document, the signing certificate, and the trust framework — not just a single mathematical hash comparison.

The common shorthand is that you verify a digital signature by recomputing the document hash and confirming it matches the signature produced by the signing private key. That check is the first stage of validation, not the whole of it. Under ETSI EN 319 102-1 — the European Norm that codifies AdES creation and validation procedures — verification is a structured procedure that runs five stages in sequence. The mathematical check is the cheapest and the first to fail; the operational checks behind it are where most verification failures actually happen in production audits.

The framing that matters at the engineering desk is the distinction between cryptographically intact and operationally verifiable. A signature that passes the hash check is cryptographically intact: the document has not been altered since signing, and the holder of the corresponding private key produced the signature. A signature that passes all five stages is operationally verifiable: the signing certificate was issued by a trusted authority, the certificate was valid and not revoked at the signing moment, the cryptographic algorithms used were acceptable under policy at the signing moment, and the signing moment itself can be established with sufficient assurance. The operational check is what regulators and auditors actually ask about; the cryptographic check is what the engineer reaches for first.

The pattern I see in production deployments comes up over and over: most verification implementations cover stages one and two — hash check and certificate chain resolution — and stop. The remaining stages (revocation, algorithm policy, signing time) get treated as edge cases. Under eIDAS Article 32, they are not edge cases; they are part of the legal verification requirement. A signature that stops at stage two passes a technical check but does not satisfy the eIDAS validation procedure. That gap is where audit incidents accumulate through 2026 and 2027.

How do you walk through the verification chain step by step?

Stage by stage — each stage answers a specific question with a clear pass/fail outcome and a defined remediation if it fails.

Stage 1 — Document integrity. Compute the cryptographic hash of the signed document and compare it to the hash bound by the signature. If the hashes match, the document has not been altered since the signature was produced; if they do not match, the signature is INVALID under ETSI 319 102-1, and no further checks proceed. The hash function used must match what the signature specifies — SHA-256 is the dominant choice in 2026 production; SHA-384 and SHA-512 appear in higher-assurance contexts; SHA-1 is deprecated and should fail at this stage if encountered.

Stage 2 — Certificate chain resolution. Take the X.509 signing certificate referenced in the signature, walk its issuer chain back to a trust anchor, and confirm each intermediate certificate's signature against its issuer. The trust anchor is what the verifier already trusts — typically a Certificate Authority root certificate that the verifier has loaded from a trusted source. Under eIDAS, that trusted source for AdES and QES signatures is the EU Trusted List (LOTL), which we cover in detail in the next section. If the chain cannot be resolved to a known trust anchor, the signature is INDETERMINATE — not invalid, but not verifiable either. The verifier knows the signature is mathematically correct but cannot establish the issuer's authority.

Stage 3 — Revocation status at signing time. For each certificate in the chain, check its revocation status as of the signing moment. This typically uses a Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP). The historical check is the tricky part — the verifier needs to know whether the certificate was revoked at the signing time, not now. A certificate that is valid now but was revoked at signing time produces an invalid signature. A certificate that is revoked now but was valid at signing time produces a valid signature, provided the historical revocation data is retrievable. If revocation status at the signing moment cannot be established, the signature is INDETERMINATE. If the certificate was revoked at the signing moment, the signature is INVALID.

Stage 4 — Algorithm policy at signing time. Confirm that the cryptographic algorithms used by the signature were acceptable under policy at the signing moment. The reference is ETSI TS 119 312, which publishes the acceptable cryptographic suites for advanced electronic signatures and their evolution over time. A signature produced in 2018 using SHA-1 was acceptable then but is not acceptable now; the verifier checks whether the algorithm was acceptable at the signing moment, not whether it is acceptable today. If the algorithm was not acceptable at signing time, the signature is INDETERMINATE — the cryptographic primitive has known weaknesses that compromise the binding.

Stage 5 — Signing time validation. Establish the signing moment to a defined assurance level. The signature carries a claimed signing time from the signer's clock; that claim is unreliable on its own. For higher-assurance verification — particularly for long-term retention — the signing moment needs to be anchored by a Qualified Timestamp from a QTSP under eIDAS Article 41-42. If only the claimed time is available, the signature is verifiable but the time assertion is weak; for our customers this is the most common reason a signature passes stages 1-4 cleanly but ends up INDETERMINATE at stage 5. (See our earlier post on long-term validity for the deeper treatment of timestamps and LTV under PAdES-LTA / XAdES-A / CAdES-LTA.)

What the five-stage procedure produces is a verification report, not a binary pass/fail. The report names which stages passed, which failed, and the specific reason. The terminal status is one of TOTAL_PASSED (all five stages clean), TOTAL_FAILED (a stage produced INVALID), or INDETERMINATE (a stage could not be conclusively resolved). The verifier-side question is which of these the integrating system is willing to act on; the regulator-side question is which of these the regulation requires for the use case.

Where does the EU Trusted List fit in the verification chain?

At the trust-anchor resolution step. The EU Trusted List is what tells a verifier which Certificate Authorities and Trust Service Providers carry eIDAS-recognised authority, and what level of assurance they carry it at.

The EU Trusted List (LOTL) browser is the authoritative public index of all Trust Service Providers operating under eIDAS Articles 21-24. Each Member State publishes its national trusted list with the TSPs that operate under its supervision; the European Commission publishes the List of Trusted Lists (LOTL) that federates the Member State lists into one source of truth. A verifier validating a signature follows the certificate chain to whatever Certificate Authority issued the signing certificate, then resolves that CA's identity against the LOTL.

What the LOTL tells the verifier is more than just "this CA exists". It tells the verifier the assurance type the TSP is recognised for — qualified certificate for electronic signature, qualified certificate for electronic seal, qualified timestamp service, qualified preservation service, qualified validation service. The same TSP can be listed for multiple service types with different assurance qualifiers per service. The verifier matches the assurance type the signature is claiming against what the LOTL says the TSP is actually qualified for. A signature claiming QES status with a signing certificate from a TSP not qualified to issue QES certificates fails the eIDAS validation, even if the mathematical chain is intact.

The architectural choice that makes the LOTL workable at scale is that it is a cryptographically signed document. Each Member State list is signed by the publishing authority; the LOTL itself is signed by the European Commission. A verifier loading the LOTL validates the signatures before trusting any of the entries. The signature on the LOTL terminates at a Commission-published root key that the verifier loads out-of-band — the bootstrapping problem solved by manual key distribution rather than by signature chain. Under Commission Implementing Decision (EU) 2015/1505, the LOTL publication format and signing rules are standardised across Member States.

Said plainly: the LOTL is the load-bearing trust component for the entire AdES and QES verification ecosystem in the EU. If the LOTL infrastructure fails, every eIDAS-anchored signature becomes operationally unverifiable until it recovers. The Commission and the Member State publishing authorities run high-availability infrastructure for this reason; the verifier-side caching strategies (refresh interval, fallback caches, signed-snapshot retention) are what most production implementations get wrong on the first attempt.

What changes for long-term verification — and where does IdentiGate sit?

The verification chain runs the same way at month 48 as at month 1 — but the evidence has to have been captured at month 1 for the month-48 check to resolve. That capture step is where AdES profiles diverge into archival variants, and where the foundation-layer identity-proofing IdentiGate ships becomes the audit anchor that survives the longest.

When a verifier runs the five-stage procedure at month 1 — within the validity period of every certificate in the chain — every check resolves against live infrastructure. The CA's CRL is current; the OCSP responder answers; the algorithm policy at the signing moment is recent; the EU Trusted List's record for the issuing TSP is the same as it was at signing. The verification report comes back TOTAL_PASSED and the signature is established as authentic.

When the verifier runs the same procedure at month 48, the signing certificate may have expired (typical CA-issued certificates are valid for one to three years); the CRL for the certificate may have been retired (CAs typically stop publishing revocation status seven to thirteen years after certificate expiry); the issuing TSP may have ceased operations or moved off the EU Trusted List; the algorithm policy may have evolved (SHA-256 is fine in 2026 but the deprecation horizon under ETSI TS 119 312 starts to bite in the early 2030s). Without archival evidence captured at signing time, the verification at month 48 produces INDETERMINATE rather than TOTAL_PASSED — the signature is still cryptographically intact, but the operational evidence chain has degraded.

The AdES archival profiles — PAdES-LTA, XAdES-A, CAdES-LTA — are designed to capture the evidence at signing time so that the verification at month 48 has something to validate against. The profile wraps the signature with the validation data (full certificate chain, revocation status at signing time, algorithm policy reference), a Qualified Timestamp from a QTSP, and a periodic re-timestamping cadence that keeps the wrapper itself current. We covered this in our long-term validity post; the verification angle here is that the LTV wrapper is what the stage-5 verification reads at month 48. Without the wrapper, the verification fails at stage 5 even though the cryptographic primitive is intact.

Where IdentiGate sits in this picture is at the identity-proofing primitive underneath the signing certificate. The Identity Verification product produces the chip-anchored AdES-bound record that the signing flow consumes to establish who the signer is at the moment of signing — passport NFC chip read for the 179 ICAO 9303 countries, or document authenticity plus biometric face match for every remaining country, AdES-bound under eIDAS Article 26. The Signatures product produces the AdES signature that the verifier subsequently runs the five-stage procedure against. The Evidence Layer product retains the verified record (signature plus validation data plus identity proofing) in a form that survives the month-48 audit. The verifier walking through the five-stage chain at month 48 is reading evidence that the foundation-layer proofing primitive established at month 0.

Where I disagree with the loud-on-LinkedIn position is the implication that verification is a black-box check the integrating system can outsource to a SaaS endpoint. The five-stage procedure is the regulatory requirement; the report it produces is what survives audit; the integrating system has to retain that report and the evidence behind it. A SaaS endpoint that returns valid or invalid without naming which of the five stages produced the result is not enough for the eIDAS validation requirement under Article 32 — it answers the engineering question but not the regulatory one. The verifier infrastructure has to produce the structured report, and the system integrating it has to retain that report alongside the signed document for the retention period the use case demands. Get that retention right and the signature stays verifiable for decades; get it wrong and the cryptographic intactness becomes operationally moot.

Sources

Primary — eIDAS and signature framework

Primary — ETSI validation standards

Primary — IETF PKI standards

About the author

Gustav Poola is co-founder of IdentiGate. He focuses on the technical architecture of passport-chip identity verification, advanced electronic signature production under eIDAS, and the engineering of identity flows that survive regulator and auditor walk-back.

The signature carries the burden of proof — but the burden falls back on whoever relied on it if the evidence chain behind the signature isn't complete. Under eIDAS Article 25(2), Qualified Electronic Signatures presume authenticity unless the challenger rebuts it. For Advanced signatures, the party asserting the signature has to demonstrate identity binding, integrity, and time — and courts have been consistent since 2020 that thin proofing evidence loses the case.

Strictly speaking, digital signatures don't encrypt anything — they use asymmetric cryptography to sign a hash of the data. The signer's private key transforms the hash into a signature; the corresponding public key verifies it. In 2026 production: RSA-PSS with SHA-256 (RFC 8017), ECDSA over P-256 or P-384 (RFC 6979), and Ed25519 (RFC 8032). ETSI TS 119 312 sets which cryptographic suites are acceptable for AdES, and the post-quantum migration is starting to reshape the algorithm shortlist through 2030.

Three things stacked in the right order under eIDAS Article 25: non-discrimination in principle for any electronic signature, equivalence to a handwritten signature only for Qualified Electronic Signatures under Article 25(2), and successful validation under the Article 32 procedure. The gap that costs cases in court is between 'the signature exists' and 'the signature validates against Article 32 requirements' — and the identity-proofing under the signing certificate is where most legal-validity claims quietly break.