Digital Signatures: Format, Certificate, and Validation Policy Are Not the Same Thing

The right move when a digital signature fails validation is don't look at the cryptography first. I know that sounds backwards. If the algorithm is RSA-2048 and the certificate chain is intact, why would validation fail? Because a signature can be cryptographically perfect and still get rejected by the validator. The problem isn't the hash or the private key — it's the format, the wrong certificate, or the validation policy the system is applying.

My thesis is simple: most errors that look cryptographic in digital signatures are actually upper-layer errors — incompatible format, a certificate that doesn't meet the required profile, or a validation policy that the issuer and receiver never aligned on. And confusing those three layers has a real cost: debugging time wasted in the wrong place.

The Real Mess: Three Layers People Keep Mixing Up

When a digital signature fails validation, the typical mental sequence is: "Is the algorithm correct? Does the private key match the public one? Did the certificate expire?" Those are reasonable questions, but they're all in the same layer. The problem is there are three distinct layers, and each one can fail independently.

Layer 1 — Signature Format

The format defines how the signature is packaged together with the signed data. CMS/PKCS#7 is not the same as XAdES, PAdES, or JAdES. Each has variants: BASELINE-B, BASELINE-T, BASELINE-LT, BASELINE-LTA. Choosing CAdES-BASELINE-B when the receiver expects XAdES-BASELINE-LT produces a rejection that has nothing to do with the cryptographic algorithm.

The public documentation for DSS (Digital Signature Service) from the European Commission describes these variants in detail. DSS is the reference library for eIDAS-compliant signatures, and its documentation is one of the most complete and verifiable resources publicly available.

Layer 2 — Certificate

The certificate is the signer's identity, but it's also a set of constraints. The Key Usage field defines what the key can be used for: digital signature, encryption, certificate signing. If the certificate was issued for one purpose and used for another, the validator can reject it even when the mathematical signature is correct.

Then there's the trust chain. A certificate issued by a root CA that the validator doesn't have in its trust store produces a "certificate not trusted" error — another error that's not cryptographic, it's configuration.

Layer 3 — Validation Policy

The policy defines the rules the validator applies to accept or reject a signature. Two systems can use the same format and the same valid certificate, and one accepts the signature while the other rejects it — because their validation policies differ.

The policy might require, for example, that the signature include a timestamp from a trusted TSA (Time Stamping Authority). A BASELINE-B signature doesn't include a timestamp. If the policy requires one, the rejection is a policy failure, not a cryptography failure.

What DSS Says — and What It Doesn't

The official DSS documentation explains the format variants (CAdES, XAdES, PAdES, JAdES) and their conformance levels. It also describes the validation model it implements, based on ETSI EN 319 102 and 319 132.

What DSS says:

• Each BASELINE level adds attributes on top of the previous one. T adds a timestamp, LT adds revocation material (OCSP/CRL), LTA adds long-term archival.
• Validation in DSS can be configured with different policies. The default policy is not universal — each implementation can define its own.
• DSS provides a set of XML validation reports that break down errors by layer: signature, certificate, timestamp, policy.

What DSS doesn't say:

• It doesn't define which format to use in a specific regulatory context — that's defined by the applicable regulation in each jurisdiction.
• It doesn't guarantee that a certificate issued by any CA will be accepted by any validator. The list of trusted CAs is a policy decision.
• It doesn't replace legal advice about the legal weight of a signature in each country.

This matters: DSS is a technical reference tool, not a regulatory authority. Using DSS correctly doesn't guarantee legal compliance — it guarantees technical correctness within the model DSS implements.

Where People Go Wrong — and What It Costs

The most common error I see documented in technical forums and in the DSS repository's own issues goes like this: the developer gets a validation error, assumes the problem is the algorithm or the key, switches signature providers, and the error persists. Because the problem was the format.

A concrete example: an XAdES-BASELINE-B signature is technically valid — it has the signature, the signer's certificate, and the required attributes for that level. But if the receiver expects XAdES-BASELINE-LT (which includes embedded revocation material), the validator rejects it on policy grounds, not cryptographic ones. The signature is mathematically correct. The format doesn't meet the required level.

The hidden cost of mixing up the layers is circular debugging: you verify the key, regenerate the certificate, change the algorithm — and nothing changes, because the problem was which format variant you chose or what policy the validator applies.

A simple criterion before debugging: DSS validation errors always indicate which layer the failure occurred in. The XML report DSS generates separates results into BasicBuildingBlocks, Timestamps, CertificateChain, and SignatureQualification. If the error is in BasicBuildingBlocks / FC (Format Checking), it's not cryptography. If it's in CertificateChain, it's not the signing algorithm.

Decision Checklist: What to Look at First

Before changing anything in the signature stack, this is the order that actually makes sense:

• ✓ 1. FORMAT

  • Does the chosen format (CAdES/XAdES/PAdES/JAdES) match what the receiver expects?
  • Does the BASELINE level (B / T / LT / LTA) satisfy what the receiver's policy requires?
  • If you're using DSS: are SignatureForm and SignatureLevel configured correctly?

• ✓ 2. CERTIFICATE

  • Does the certificate's Key Usage include "digitalSignature"?
  • Is the certification chain complete (leaf → intermediate → root)?
  • Was the certificate within its validity period at the time of signing?
  • Is the issuing CA in the validator's trust store?

• ✓ 3. VALIDATION POLICY

  • Does the validator use a policy that requires a timestamp? Does the signature include one?
  • Is embedded OCSP or CRL required (LT level)?
  • Does the validator have an up-to-date Trusted List (e.g., eIDAS LOTL)?

• ✓ 4. VALIDATION REPORT

  • If you're using DSS: read the validation XML and locate the block with the error.
  • Identify whether the error is in Format Checking, Certificate Chain, Revocation, or Policy.
  • Don't change anything until you understand which layer the error landed in.

This checklist doesn't replace validator logs, but it cuts off the most common circular debugging loop before it starts.

Limits: What You Can't Conclude Without Your Own Data

Before wrapping up, I want to be honest about what this guide cannot guarantee:

• I can't tell you which format is correct in each jurisdiction. Regulations change, and legal compliance depends on the applicable framework (eIDAS in Europe, but every country has its own implementation). For that, the source is the current regulation and a legal advisor, not a technical post.
• I can't claim DSS is the only valid tool. It's the European Commission's reference library and it's well documented, but other implementations exist. The choice depends on context.
• The checklist above is a diagnostic criterion, not a conformance guarantee. If the target system has a custom validation policy or its own Trusted List, there will be edge cases the checklist doesn't cover.
• Without validator logs, any diagnosis is speculation. The DSS XML report is the most reliable evidence available for debugging. Without it, everything else is a hypothesis.

If you're in real production with legal weight attached, technical diagnosis is necessary but not sufficient. The legal layer exists and doesn't disappear just because you got the format right.

FAQ

What's the concrete difference between CAdES, XAdES, PAdES, and JAdES?

They're signature formats that differ in the type of content they sign and how they package it. CAdES signs binary data using CMS. XAdES signs XML documents. PAdES signs PDF documents. JAdES signs JSON. All are defined in ETSI standards and all share the same BASELINE levels (B, T, LT, LTA). The choice depends on the type of document being signed, not on the cryptographic algorithm.

What is BASELINE-LT and why does it matter?

BASELINE-LT (Long-Term) embeds the certificate's revocation material — OCSP response or CRL — in the signature package at signing time. This allows the signature to be validated long after the fact without needing to query external services that may no longer exist. It's the minimum recommended level when the signature needs to hold value over time.

Does an expired certificate always invalidate the signature?

It depends on the validation policy. If the signature includes a valid timestamp (level T or above) that was generated while the certificate was still valid, many validators accept the signature even if the certificate has since expired. That's exactly the point of the timestamp: it anchors the signature in time.

What is the Trusted List (LOTL) in eIDAS and why does it affect validation?

The LOTL (List of Trusted Lists) is the official registry of trusted CAs under the eIDAS framework. Validators that want to determine whether a signature is "qualified" under eIDAS consult that list to see if the issuing CA is recognized. If the CA isn't on it, the signature may be technically valid but won't qualify as a Qualified Electronic Signature.

Does DSS validate whether a signature has legal value?

Not directly. DSS validates technical conformance with ETSI profiles and reports the qualification level according to the configured policy. But legal value depends on the regulations of each jurisdiction. DSS can say a signature is "QES" (Qualified Electronic Signature) technically — whether that carries the same legal weight as a handwritten signature in a given country is something the legal framework says, not the library.

Can I test signature validation without building my own full stack?

Yes. DSS has a public demo webapp where you can upload a signed document and get a validation report. It's genuinely useful for understanding what the validator reports before you implement anything. The link is in the sources at the bottom of this post.

Final Take: Don't Break What You Don't Understand

When a digital signature fails, the instinct is to change the algorithm, regenerate the certificate, or switch libraries. That instinct is wrong most of the time.

My point is this: before touching anything, open the validation report. If you're using DSS, it's in XML and it's readable. Identify which layer failed — format, certificate, or policy. Only then do you know where to act.

What bothers me most about this topic is that the confusion between these three layers isn't technical ignorance — it's a missing mental model. Cryptography is the sexy part, so all the debugging energy goes there. But the digital signature ecosystem has two more layers on top of it that are equally decisive and much easier to fix once you identify them correctly.

The concrete next step: if you're integrating signature validation, download the DSS webapp, sign a test document with different levels, and read the XML validation report before writing a single line of production code. That'll save more time than any blog post.

For other topics where the ecosystem has more layers than it first appears, these posts might add useful context: how to evaluate npm dependencies before adding them to production, rate limiting in Next.js and what to protect first, or OWASP LLM Top 10 in production.

Original source:

• European Commission DSS documentation: https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/doc/dss-documentation.html