Probatioby AcquisizioniForensi
IT EN
Download
Home / Guides / Digital signature

What «valid signature» really means

Digital signature 11 July 2026

«The signature is valid» is a sentence standing in for three distinct claims, and anyone who collapses them into one loses the cross-examination. Verifying a digital signature means answering three questions separately, and each can fail while the other two succeed.

The three questions

1 Integrity «is the document the one that was signed?» The document's digest matches the one that was signed. Pure mathematics. Yes or no. 2 Trust «whose key did the signing?» The certificate chains up to a recognised root (AgID). Certificate chain. 3 Time «was it valid when they signed?» Certificate neither expired nor revoked at that date. Timestamp + OCSP. The three answers are independent. A signature can be mathematically intact and made with a revoked certificate. Or valid and issued by an unknown authority. «Valid signature», without saying which of the three, is a sentence with no content.
Any serious verifier answers all three. The risk is not that one fails: it is that the reader of the report believes only one question was asked.

Question 1 — integrity

The simplest, and the only purely mathematical one. The signed digest is extracted from the envelope, the document's digest is recomputed, and the two are compared. If they differ, the document changed after signing and every other question becomes idle.

Probatio verifies the signature with the algorithm declared in the certificate. The supported ones are RSA PKCS#1 v1.5 (with SHA-1, SHA-256, SHA-384, SHA-512), RSA-PSS, ECDSA on the P-256 and P-384 curves, and Ed25519. A certificate using anything else is rejected, not «approved out of caution».

Question 2 — the chain of trust

The signer's certificate says «this key belongs to Mario Rossi». But it is the certificate saying it — a file anyone can fabricate. For that claim to be worth something, it must be signed by someone else: a Certification Authority. And the CA's certificate, in turn, must be signed by someone.

The chain stops when it reaches a trust anchor: a certificate signed by nobody, because we decided so upstream. The roots are not chosen at random: eIDAS (Article 22) requires every member state to publish a trusted list of its qualified providers. In Italy that list is published and maintained by AgID, and it feeds into the European list. Probatio builds the path from the signer's certificate up to one of those roots.

If the chain does not close, the signature is mathematically perfect and legally mute: nobody vouches that the key is Mario Rossi's.

What the certificate reveals

Beyond the name, Probatio extracts the tax code (the TINIT- prefix in Italian certificates), the organisation, the issuer, the serial number, the validity period, the key type and the permitted usage — in particular the nonRepudiation flag, which distinguishes a signing certificate from an authentication one. It also recognises CIE certificates, the Italian electronic identity card.

Qualified or not: the QCStatements

Inside the certificate there may be an extension declaring conformity with the eIDAS regulation. Probatio reads two indicators from it:

  • QcCompliance — the certificate is qualified: issued by a qualified trust service provider listed in the European trusted lists.
  • QcSSCD — the private key resides on a qualified signature creation device (a certified smart card, not a file on disk).

The distinction is not formal, but it must be stated precisely, because this is where simplifications do damage.

The eIDAS Regulation, at Article 25(2), provides that «a qualified electronic signature shall have the equivalent legal effect of a handwritten signature». Article 25(1) adds that an electronic signature which is not qualified shall not be denied legal effect and admissibility as evidence merely because it is electronic.

In Italy the picture is completed by the Digital Administration Code (CAD). Article 20(1-bis) provides that an electronic document satisfies the written-form requirement and carries the effect of Article 2702 of the Civil Code when a digital, qualified or advanced electronic signature is affixed. An advanced signature therefore produces that effect too: anyone claiming otherwise is wrong.

The real differences are two others:

  • The presumption of attribution. Use of a qualified or digital signature device is presumed attributable to the holder unless they prove otherwise. That presumption does not extend to an advanced signature.
  • The deeds listed in Article 1350 of the Civil Code (items 1 to 12: property transfers, mortgages and the like) must be signed, on pain of nullity, with a qualified or digital signature. An advanced signature is not enough.

Knowing whether a signature is qualified does not tell you whether it «counts»: it tells you who must prove what, and for which deeds it is admissible. Exactly the kind of distinction an expert report must carry without rounding it off.

Question 3 — time, and why it is the trickiest

A certificate typically lasts three years. The document in your hands may have been signed six years ago. The certificate has expired. Is the signature invalid?

No — provided you can prove when it was affixed.

certificate valid certificate expired issuedexpirestoday signing declared signingTime RFC 3161 timestamp best signature time Timestamped: valid checked at the timestamp date Not timestamped: checked at today certificate expired → negative result signingTime is declared by the signer: an assertion, not a proof. A timestamp is declared by a third party: a proof.
The best signature time is the instant against which expiry and revocation are assessed. Without a timestamp that instant is «now» — which is why untimestamped signatures age badly.

Inside the CMS envelope the signer may include a signingTime attribute: the hour at which they say they signed. That is their computer's clock, and anyone can set it. It proves nothing.

What does prove something is an RFC 3161 timestamp embedded in the envelope's unsigned attributes: a third-party authority signed the digest of the signature together with the time. Probatio extracts it and uses it as the best signature time, the instant against which certificate validity and revocation are assessed.

If the timestamp is missing, there is no provable instant and verification falls back on the current time. That is why the signature level matters so much:

  • -BES (Basic Electronic Signature): the signature and nothing more. It holds as long as the certificate is valid.
  • -T (Timestamp): the signature plus at least one timestamp. It survives the certificate's expiry.

Probatio computes the level by counting the timestamps present: CAdES-T, PAdES-BES, and so on.

Mind the nomenclature, because two generations of standards coexist. -BES and -T come from the historical ETSI specifications (TS 101 733). The standards in force today — EN 319 122-1 for CAdES, EN 319 142-1 for PAdES — call the same levels B-B and B-T, and add B-LT and B-LTA for long-term validity, which embed the validation material (certificates and revocation responses) into the signature itself. In a report, cite both spellings.

Revocation

A certificate may be revoked before it expires: a lost smart card, a change of role, a compromise. A revoked certificate is worthless — but signatures affixed before the revocation remain valid, if a timestamp proves it.

Probatio checks revocation over OCSP (Online Certificate Status Protocol): it extracts the responder's address from the certificate's AIA extension and asks it, in real time, whether that serial number has been revoked.

Probatio does not download CRLs, the revocation lists. If the certificate publishes no reachable OCSP responder, the revocation status comes back as unavailable — which does not mean «valid».

That distinction must be reported precisely. «Revocation not verifiable» is an outcome, not a technical detail to be omitted.

What you will not find

  • No CRLs. Only online OCSP, as explained above.
  • No countersignatures. The CMS countersignature attribute is not extracted: among the unsigned attributes, Probatio looks for timestamp tokens.
  • No ASiC. The .asice and .asics containers are not handled.

How to write it in a report

Not «the signature is valid». Rather, three sentences:

  1. Integrity: «the document's SHA-256 digest matches the signed one; the document has not been modified since signing».
  2. Attribution: «the signer's certificate, issued to name, tax code xxx, chains to a root present in the AgID list; it bears the QCStatements for qualified signature and qualified device».
  3. Time: «the signature bears an RFC 3161 timestamp of date, issued by TSA; at that date the certificate was valid and not revoked according to the OCSP response obtained».

Three claims, three different foundations, each contestable on its own. It is inconvenient, and it is the only honest way to put it.

Keep reading