Digital signatures: format, certificate, and validation policy — three layers people constantly mix up

I was deep in a validation error that made no sense. The cryptography was fine — I'd checked the hash, the algorithm, the key length. Three hours in, I found the actual problem: the document was CAdES-BES and the receiving system expected CAdES-LT. No timestamp, no embedded revocation material. The validator returned INVALID and I'd spent the whole morning looking in completely the wrong place.

My thesis is straightforward: most digital signature errors aren't cryptographic problems. They're format or validation policy problems. And the instinct to dive straight into algorithms and keys is the thing that costs you hours.

The three layers you need to separate

The confusion starts when people treat "digital signature" as a single thing. It isn't. It's three independent layers that can fail for completely different reasons.

Layer 1 — The document format

The format defines how the signature is packaged with the document. In European and regulated ecosystems, the main ones are:

• CAdES (CMS Advanced Electronic Signatures): for arbitrary binary data, common in backend systems.
• XAdES (XML Advanced Electronic Signatures): for XML documents, with variants that let you sign specific nodes.
• PAdES (PDF Advanced Electronic Signatures): embedded in PDF, with long-term validation support built in.
• JAdES (JSON Advanced Electronic Signatures): the newest, for JSON-based flows.

Each format has internal profiles: BES, T, LT, LTA. T adds a timestamp. LT embeds revocation material (OCSP or CRL). LTA timestamps the validation material itself.

A CAdES-BES signature sent to a system expecting CAdES-LT returns INVALID — even with perfect cryptography, a valid certificate, and a correct hash. The format mismatch kills it before the cryptographic check matters.

Layer 2 — The certificate

The certificate is the signer's identity. Typical failure modes:

• Incomplete chain: the signer's cert is valid, but the validator's trust store doesn't have the root CA.
• Revocation: the cert was revoked and the validator checks OCSP or CRL. If the revocation endpoint doesn't respond, depending on policy that can be an error or just a warning.
• Key Usage: digitalSignature isn't explicitly set.
• Signing time outside validity period: the cert expired between signing and validation, and there's no timestamp to anchor the signature to the moment it was still valid.

Layer 3 — The validation policy

This is where most people get genuinely lost. A validation policy is a set of rules defining what counts as "valid" for a specific context. It is not universal.

eIDAS (Regulation EU 910/2014) defines signature levels — Simple, Advanced, Qualified — but the concrete rules of what a system actually checks depend on the policy configured in the validator. Two systems both implementing eIDAS can reach different verdicts on the same signature if their policies differ. That's not a bug. It's intentional.

Diagnosis checklist: run this before touching cryptographic code

Only after going through all six without finding the problem should you look at cryptography: hash, algorithm, key length.

DSS from the European Commission: what it tells you and what it doesn't

The reference library for this ecosystem is DSS (Digital Signature Service), maintained by the European Commission. Documentation: https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/doc/dss-documentation.html.

DSS supports all four formats and their profiles, and it exposes a validator that returns a detailed report in XML or JSON with per-layer diagnostics. It's Java, open source (LGPL), and it's the engine behind several national European validators.

What DSS tells you: how each format is structured, what each profile expects, what the validator checks at each step.

What DSS doesn't tell you: which validation policy is mandatory for your specific use case. That's defined by local regulation, the contract with the receiver, or the technical spec of the consuming system. DSS gives you the tool; the correct policy you have to source separately.

A reproducible Java example with DSS

// Load the signed document (CAdES example)
DSSDocument signedDocument = new FileDocument("signed-document.p7s");

// Configure certificate and revocation sources
CertificateVerifier verifier = new CommonCertificateVerifier();
// Add trust store with the root CAs you want to accept
verifier.setTrustedCertSources(trustedCertificateSource);
// Configure online OCSP source (optional, can be offline)
verifier.setOcspSource(new OnlineOCSPSource());

// Create the validation service
DocumentValidator validator = new CMSDocumentValidator(signedDocument);
validator.setCertificateVerifier(verifier);

// Run validation with default EIDAS_MODEL policy
Reports reports = validator.validateDocument();

// The diagnostic is in the detailed report
DiagnosticData diagnosticData = reports.getDiagnosticData();
SimpleReport simpleReport = reports.getSimpleReport();

// Per signature: indication, sub-indication, and errors/warnings
for (String signatureId : simpleReport.getSignatureIdList()) {
    System.out.println("Indication: " + simpleReport.getIndication(signatureId));
    System.out.println("Sub-indication: " + simpleReport.getSubIndication(signatureId));
    // The errors tell you exactly which layer failed
    simpleReport.getErrors(signatureId).forEach(System.out::println);
}

The important thing isn't the code itself — DSS documentation covers that. It's the sub-indication. When getIndication returns INDETERMINATE or INVALID, getSubIndication tells you whether the problem is NO_CERTIFICATE_CHAIN_FOUND, REVOKED_NO_POE, SIG_CONSTRAINTS_FAILURE, or one of the other codes defined in ETSI EN 319 102-1. Each one points to a different layer. That's the diagnostic, not the top-level result.

The errors that actually cost hours

Error 1: Chasing the algorithm when the problem is the profile

CAdES-BES sent to a system expecting CAdES-LT returns INDETERMINATE / NO_POE. The automatic reading is "cryptography problem." The actual fix is upgrading the signature profile to include revocation material — nothing to do with the algorithm.

Error 2: Assuming a "valid" certificate is sufficient

A cert can pass chain verification and revocation checking but have Key Usage without digitalSignature set. DSS reports this as SIG_CONSTRAINTS_FAILURE. The certificate is current; the signature is still invalid.

Error 3: Ignoring the validator's trust store

If the validator uses the European LOTL as its trust anchor, it only recognizes certificates from CAs that appear in that list. A perfectly valid certificate from a CA outside the LOTL gives NO_CERTIFICATE_CHAIN_FOUND. That's not an error in the signature — it's a validator misconfiguration or a policy incompatibility.

Error 4: Conflating technical validation with legal validation

DSS can return TOTAL-PASSED under a given policy. That doesn't mean the signature has legal validity in a specific jurisdiction. Qualified eIDAS signatures require the certificate to come from a QTSP listed in the LOTL. A technical validator doesn't replace legal analysis.

Limits of what you can conclude without real data

Being honest about the edges of this analysis:

• You can't determine the correct policy for a specific case from general documentation alone. The policy is defined by the receiver or applicable regulation and can vary between systems implementing the same standard.
• The code examples are illustrative, not production configurations. Real implementations need error handling, OCSP timeout settings, revocation caching, and explicit decisions about what to do when revocation services don't respond.
• DSS sub-indications are precise for what DSS verifies, but if the receiver uses a different validator, results may differ. Interoperability between validators is an open problem in this ecosystem.
• eIDAS is European. For other regulatory contexts — NIST, PKCS#11 in Latin American banking, etc. — the layers are analogous but the policy specifics change.

The reference table I use as a first orientation:

FAQ

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

The format depends mainly on document type. CAdES handles arbitrary binary data. XAdES handles XML where you may need to sign specific nodes. PAdES is for PDFs with built-in longevity and visual support. The choice isn't free — it's defined by the receiving system.

What is an LT profile and why does it matter?

LT (Long-Term) means the signature embeds revocation material at signing time. This lets you validate the signature years later without depending on revocation endpoints from that moment still being alive. It's mandatory in many regulated contexts for exactly this reason.

Why can a valid certificate produce an invalid signature?

Because currency and validity for signing are different things. A certificate can be current but have wrong Key Usage, come from a CA not in the validator's trust store, or have been issued after the recorded signing moment. Necessary, not sufficient.

What is the LOTL?

The LOTL (List of Trusted Lists) is an XML document maintained by the European Commission referencing national lists of qualified trust service providers from each member state. Validators implementing eIDAS use it as a trust anchor. Publicly available at https://ec.europa.eu/tools/lotl/eu-lotl.xml.

What does INDETERMINATE vs INVALID mean in DSS?

INVALID is a definitive failure: the cryptography doesn't hold, the certificate was revoked at signing time, or there's a hard constraint violation. INDETERMINATE means validity can't be determined with the available information — no timestamp to anchor the signing moment, revocation service didn't respond. INDETERMINATE is not synonymous with invalid: in some cases it resolves by adding validation material or adjusting the applied policy.

Does it make sense to ship digital signature code without understanding these three layers?

You can get away with it until interoperability or legal validation breaks. When it does, the wrong diagnosis — looking at cryptography when the problem is policy — is what turns a ten-minute fix into a three-hour one.

The layer to check first isn't the obvious one

The instinct to go straight to cryptography when a signature fails is understandable. It's also almost always wrong.

What I do accept from DSS and the eIDAS ecosystem: the layer separation isn't academic overhead, it's a diagnostic tool. Knowing the sub-indication tells you exactly where to look.

What I don't accept: the framing that digital signature implementation is mainly about choosing the right algorithm. The algorithm is rarely the problem. The validation policy, the misconfigured trust store, and the wrong signature profile are what actually fail in practice — and none of them surface if you're only looking at cryptography.

The concrete next step: set up DSS in standalone mode, take a signature you already have, run the validation, and read the full XML report. Not the simpleReport — the detailedReport. That's where the per-layer diagnostic lives, the one that saves the three hours.

If this kind of layer-based diagnosis feels familiar from other contexts, it should — there's something structurally similar in distributed tracing: the top-level indicator says OK, the trace shows where it actually broke. The pattern of a misleading high-level result hiding a layer-specific failure shows up across a lot of systems.

Original source:

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