People say "digital signature" and "electronic signature" as if they are the same thing. They are not. An electronic signature is a legal concept — any mark made with intent to sign. A digital signature is a specific cryptographic mechanism: a number, computed with a private key, that anyone holding the matching public key can check. Verifying it is not a matter of trust or opinion. It is arithmetic. Either the math reproduces, or it does not.
This is what a verifier actually computes when it decides a digital signature is genuine — and why the same three checks apply whether the signed object is a PDF, an XML invoice, or a raw file.
Independent things a verifier reproduces: the document hash, the public-key signature check, and the certificate trust chain. All three must pass
Any one failing means 'not verified' — and which one failed tells you what went wrong
The Cryptographic Message Syntax (CMS) — the IETF standard structure that carries a detached digital signature and its signed attributes
IETF, Cryptographic Message Syntax
The certificate format that binds a public key to a verified identity, issued and signed by a Certificate Authority
ITU-T X.509 / RFC 5280
What a digital signature actually is
A digital signature is built from asymmetric cryptography — a key pair. The private key is secret and held only by the signer (or, for cloud signing, inside a hardware security module on their behalf). The public key is embedded in a certificate anyone can read. What one key locks, only the other can open.
Signing runs in two steps: the software hashes the document with SHA-256 to get a short fixed-length fingerprint, then encrypts that fingerprint with the private key. That encrypted fingerprint is the signature. Verifying reverses it.
Recompute the hash
The verifier runs the exact same SHA-256 over the exact same bytes the signer hashed. This produces a fingerprint that must match what the signature commits to. One changed byte, one different fingerprint.
Check the public-key signature
The verifier decrypts the signature blob with the signer's public key, recovering the hash the signer sealed. If that recovered hash equals the recomputed hash from step 1, the signature was made by the matching private key over these exact bytes.
Walk the certificate chain
The public key came in an X.509 certificate. The verifier follows the chain of issuers up to a root Certificate Authority it already trusts. This is what ties the key to a real, vetted identity rather than an anonymous keypair.
The step everyone skips: the trust chain
Steps 1 and 2 prove the file was not altered and was signed by whoever holds a particular private key. They do not prove who that is. A self-generated keypair passes both checks perfectly and proves nothing about identity — anyone can make one in a second.
Identity comes only from step 3. The signing certificate must chain up to a Certificate Authority that a third party has vetted and that your verifier already trusts — Adobe's Approved Trust List (AATL) for PDFs, the EU Trusted List (EUTL) for eIDAS, or an enterprise's own root. A green tick with a self-signed certificate is a valid signature by an unknown signer.
Integrity says the bytes did not change. Authenticity says a specific private key signed them. Only the trust chain says whose key it was. A verifier that reports the first two and skips the third is confirming a signature by nobody in particular.
— The distinction that decides whether a signature means anything
Same math, four containers: the AdES families
The three checks above are universal. What changes between file types is the envelope that packages the signature and its metadata. ETSI standardises four, collectively called AdES (Advanced Electronic Signature) formats. Knowing which one you are looking at tells you which tool validates it.
The four ETSI AdES signature families. Same cryptographic core, different container per data type. SahlSign produces PAdES for its sealed PDFs.
| Jurisdiction | Law | Cross-border transfer rule | Intensity |
|---|---|---|---|
| CAdES | ETSI EN 319 122 | CMS Advanced Electronic Signatures. Signs any binary data using the RFC 5652 CMS structure. The general-purpose base the others build on. | Moderate |
| XAdES | ETSI EN 319 132 | XML Advanced Electronic Signatures. Signs XML documents — common for e-invoicing and government submissions across the GCC. | Moderate |
| PAdES | ETSI EN 319 142 | PDF Advanced Electronic Signatures. Embeds the signature inside the PDF itself so it travels with the document and verifies in any Acrobat reader. | Restricted |
| JAdES | ETSI TS 119 182 | JSON Advanced Electronic Signatures. Signs JSON payloads (JWS-based) — used in modern APIs and open-banking flows. | Moderate |
How to verify one, in practice
You rarely run the three checks by hand. A verifier does it for you — the trick is knowing which verifier matches the container and how to read its verdict.
Verifying a digital signature by container type
- PDF (PAdES) — open in Adobe Acrobat Reader
The signature panel reports all three checks plus timestamp and revocation. For the full byte-level walkthrough, see our guide on verifying signed PDFs.
- XML / any format — use the EU DSS validator
The European Commission's open-source Digital Signature Service validates CAdES, XAdES, PAdES, and JAdES against the full ETSI algorithm and returns a structured report naming the exact check that failed.
- Command line — OpenSSL for raw CMS
For a detached CMS signature,
openssl cms -verify -in signature.p7s -content data.bin -CAfile trusted-roots.pemruns the hash and public-key check and reports whether the chain terminates at a trusted root. - Always read past the headline verdict
"Invalid" usually means "untrusted issuer," not "forged." Check which of the three failed: hash mismatch (document changed), signature mismatch (wrong key), or chain failure (unknown signer). Each demands a different response.
The two verdicts people confuse
Cryptographically valid, identity unknown
The hash matches and the public-key check passes, but the certificate is self-signed or its CA isn't in your trust store. The math is perfect; the identity is unattested.
- The document is genuinely unaltered since signing
- The signature was made by whoever holds that private key
- You have no third-party proof of who that is
- Resolve by confirming the certificate fingerprint out-of-band, or trust the issuer CA
Hash mismatch
The recomputed fingerprint doesn't match the sealed one. The bytes changed after signing — an edit, an annotation, even re-saving in some tools.
- Document integrity failed — do not rely on this copy
- The signed content and the current content differ
- Request the original signed file from the sender and re-verify
Why SahlSign signatures verify anywhere
SahlSign seals every document as PAdES-B-T: a detached PKCS#7 (CMS) SignedData over the PDF byte range, from a publicly-trusted certificate chain, with an RFC 3161 timestamp. Because it is the standard and nothing but the standard, the three checks reproduce in any compliant verifier — you are never asked to trust our interface.
Every SahlSign PDF carries a standards-compliant digital signature: SHA-256 byte-range hash, RSA signature, publicly-trusted X.509 chain, and a EUTL-listed TSA timestamp. Verify it in Acrobat, in EU DSS, or from the command line — same result.
src/lib/pdf-seal.ts in the SahlSign source
Related reading
- How to Verify a Signed PDF — the same three checks, walked through the Adobe Acrobat interface byte by byte.
- How to Validate a PAdES Signature — the developer deep-dive: ByteRange, CMS structure, and programmatic validation with EU DSS.
- Is My Electronic Signature Legally Valid? — cryptography proves the signature; the law decides whether it also binds.
Sources
- RFC 5652 — Cryptographic Message Syntax (CMS)
- RFC 5280 — Internet X.509 Public Key Infrastructure Certificate
- ETSI EN 319 122 — CAdES digital signatures
- ETSI EN 319 132 — XAdES digital signatures
- ETSI EN 319 142 — PAdES digital signatures
- EU Commission DSS — open-source signature validator
- eIDAS Regulation (EU) 910/2014, Article 26 — requirements for advanced electronic signatures