Verifying an Electronic Signature on Your Website: Cryptography, Trust Chain, OCSP, and Timestamps

Short answer. Full verification of an electronic signature (digital signature / QES) means four levels: the signature mathematics (does the signature match the document and the key), the trust chain (can the certificate be traced to a root CA), the certificate status (has it been revoked — OCSP/CRL), and timestamps (when the signature actually existed — TSP). The verify widget from DSTUcrypt performs all four levels right in the browser, auto-detects the file format (.p7s, PDF, XML, ASiC), and returns a structured result for every signer — including the accredited field, which answers the key question: is this a QES or not. For one-off checks there is a free tool at dstucrypt.com.ua/verify — no registration required.

What "the signature is valid" really means: four verification levels

When a service says "the signature is valid," those words can hide very different amounts of work. Legally meaningful QES validation consists of four independent checks — and failing any one of them means the document cannot be trusted:

Note the fourth level: without a timestamp, the signingTime field is only a claimed time that the signer could have set arbitrarily. The trusted value is timestampTime — the time attested by a qualified TSP server.

Why a "green checkmark" without the chain and status is not verification

The most common mistake in home-grown verification is stopping at level one. The library checked the math, the signature matched — show the checkmark. But correct math on its own only proves that someone signed the document with some key. Anyone can generate a "key + certificate" pair in seconds and put an arbitrary name into the certificate.

Real trust comes only from the chain: the signer's certificate → intermediate certificates → the root of the central certification authority (CZO). And even a genuine certificate from an accredited provider could have been revoked yesterday — hence the third level, an up-to-date status via OCSP or CRL. Verification that skips levels 2–4 creates a dangerous illusion: the user sees "valid," while legally the document may be worth nothing.

How DSTUcrypt does it. The verify widget always performs full validation: cryptography + the chain up to the central CA (CZO) root + OCSP/CRL statuses + TSP timestamps. The signature format is detected automatically from the file contents, and the accredited field in the result answers directly whether it is a QES. For one-off checks there is a free online tool at /verify — the same full validation, no registration.

Attached and detached signatures

A .p7s file comes in two kinds, and this determines how you call the verification:

• Attached — the document is packed inside the CMS container together with the signature. It is one self-contained file: for verification, pass null as the second argument, and the original document is returned in the content field of the result.
• Detached — the container holds only the signature, while the document sits in a separate file (the typical pair "contract.pdf + contract.pdf.p7s"). Without the original there is nothing to verify: the second argument must be dataBytes — the bytes of the source document.

A practical rule: if a file with the same name minus the signature extension sits next to the .p7s, it is almost certainly detached, and they must be verified together.

Format auto-detection: CMS, PDF, XML, ASiC

Ukrainian document workflows live in more than just .p7s. A signature can sit inside a PDF (PAdES), in an XML document (XAdES), or in an ASiC ZIP container. The widget does not require you to specify the format — it recognizes it from the file contents:

This removes a whole class of integrator errors: the user simply submits a file, and the detected format is returned in the format field of each signer (for example, 'CAdES-T'). How the families differ and which one to choose for signing is covered in a separate article on the CAdES, PAdES, XAdES, and ASiC signature formats.

What the verification returns: a breakdown of the signers fields

The result is an overall valid verdict plus a signers array: one element per signer (a document may have several). Each element contains:

• valid and status — the verdict for this signer: TOTAL-VALID (all good), TOTAL-FAILED (verification failed), or INDETERMINATE (not enough data for a definitive conclusion).
• accredited — the key field for legal qualification. true — the certificate was issued by an accredited provider and traced to the central CA (CZO) root, i.e. this is a QES. false — the signature is cryptographically valid but not a QES. null — trust data is unavailable, accreditation was not checked. Why this difference matters legally is explained in the article on the difference between QES, digital signature, and AES.
• format — the automatically detected signature format and level.
• signingTime / timestampTime — the claimed signing time and the trusted TSP timestamp.
• ocspStatus / crlStatus — the certificate status via OCSP or CRL, if it was checked.
• signerCertId, signerName, signerOrg, signerCode — the certificate identifier, the signer's full name or entity name, the organization, and the RNOKPP/EDRPOU from the certificate.

Code: signature verification on your website

The whole integration is a single SDK import; the widget runs in an iframe on our origin, so there is nothing to host yourself:

full signature verification — the verify widget

import { embed } from 'https://dstucrypt.io/embed/dstucrypt-embed.mjs';

const verifier = await embed('verify', { mount: 'modal' });

// second argument — ONLY for a detached signature;
// for an attached signature pass null
const report = await verifier.verify(signatureBytes, null);

console.log(report.valid);          // overall verdict: all signatures valid
for (const s of report.signers) {
  s.status;         // 'TOTAL-VALID' | 'TOTAL-FAILED' | 'INDETERMINATE'
  s.valid;          // verdict for this signer
  s.accredited;     // true — accredited provider (this is a QES); false — no; null — not checked
  s.format;         // e.g. 'CAdES-T' — format detected automatically
  s.signingTime;    // claimed signing time
  s.timestampTime;  // trusted TSP timestamp, if present
  s.ocspStatus;     // certificate status via OCSP (e.g. 'GOOD')
  s.crlStatus;      // …or via CRL
  s.signerName;     // signer's name from the certificate
  s.signerOrg;      // organization
  s.signerCode;     // RNOKPP/EDRPOU
  s.signerCertId;   // certificate identifier
}
report.content?.download('document.pdf'); // embedded data of an attached signature

An important caveat for critical scenarios: browser-side verification is great for UX, but the browser is controlled by the user. If your backend makes decisions based on the verdict (accepting a document, crediting a payment) — send the signature to the server and verify it authoritatively via POST /api/verify: it performs the same full validation with the native core and likewise returns accredited for every signer.

One-off verification without code: the free tool

If you do not need an integration and just want to check a specific file — open dstucrypt.com.ua/verify. It is a free online tool with no registration: drag in a .p7s, a signed PDF, XML, or ASiC container — and get a full report for every signer: the verdict, QES or not, the provider, the certificate status, and the timestamps. For a detached signature the tool will ask you to attach the original file.

Frequently asked questions

How can I verify a .p7s signature online for free?

Open the free tool at dstucrypt.com.ua/verify and drag in the signature file — no registration needed. The format (.p7s, PDF, XML, ASiC) is detected automatically, and the verification is complete: cryptography, trust chain, certificate status via OCSP/CRL, and timestamps.

What does the accredited field in the verification result mean?

It answers whether the signature is a QES: true — the signer's certificate was issued by an accredited provider and traced to the central CA (CZO) root, i.e. it is a qualified electronic signature; false — the signature is cryptographically valid but not a QES; null — trust data is unavailable, accreditation was not checked.

When do I need to submit the original file together with the signature?

Only for a detached signature, when the .p7s contains just the signature without the data. In the verify(signatureBytes, dataBytes) call, pass the original as the second argument. For an attached signature the data is already inside the container — pass null, and the embedded content is returned in the content field.

Can browser-side signature verification be trusted?

For UX — yes: the widget honestly performs the full verification in the browser and shows the user the verdict. But if your backend makes decisions based on the verification (accepting a document, crediting a payment), verify the signature on the server via POST /api/verify — a verdict that arrived from the client's browser cannot be trusted.

Read also

• QES, digital signature, and AES: what is the difference
• Long-term electronic signatures: CAdES-XL and PAdES-LTA
• Electronic signature formats: CAdES, PAdES, XAdES, ASiC

Full QES verification on your website — in 10 minutes

Ready-made DSTU widgets for verification, signing, and encryption. Cryptography, trust chain, OCSP/CRL, and timestamps — out of the box. Try the free verification or connect the widget: every new domain gets 7 days free.

Live demoHow to connect