X.509 Digital Certificates: What They Prove

A document signature that relies on an X.509 certificate proves three things at once: who held the private key when the signature was applied, what document was hashed to produce it, and whether the certificate itself was valid and unrevoked at that moment. The certificate does not by itself make a signature legally binding in the US, but it is the technical mechanism that turns a typed name into cryptographic evidence that survives the document being forwarded, printed, or audited years later.

What an X.509 Certificate Actually Contains

The standard that defines the certificate format is RFC 5280, and the version most signing workflows produce is X.509 v3. A certificate carries the subject's distinguished name and public key, the issuer's distinguished name and signature, the validity period, the serial number, and a set of extensions. The two extensions that matter most for document signing are:

For the full list of CAs your organization typically trusts for document signing, Certificate Authority List for Browsers and E-Signatures is a working reference.

• Key Usage and Extended Key Usage: the bits that say whether the public key may be used for digital signatures, key encipherment, or both. A certificate issued for a web server will typically have serverAuth but not emailProtection or codeSigning, and that mismatch is the first thing a careful reader checks.
• Certificate Policies and CRL Distribution Points: pointers to the policy under which the certificate was issued, and where to look up whether the certificate has been revoked.

If a certificate has the wrong Key Usage extension, the signature it produces can be mathematically valid and still have no legal weight, because the certificate was never authorized to sign documents. This is one of the reasons an "any certificate" approach to signing fails in regulated workflows.

For the full list of CAs your organization typically trusts for document signing, Certificate Authority List for Browsers and E-Signatures is a working reference.

When an X.509 Certificate Is the Right Mechanism

For a US business agreement that has to be defensible three years from now, an X.509-backed signature is worth the cost when at least one of these is true:

What the certificate looks like in practice is covered in Digital Certificate Example for Secure Signing Workflows, with the field-by-field read that follows.

1. The document is filed with a regulator or recorded in a public system. Tax forms, certain court filings, and some healthcare documents require qualified or certificate-backed signatures for the receiving system to accept them.
2. The counterparty's policy requires it. Government suppliers, banks, and some enterprise procurement teams will reject a non-certificate signature even when the law does not require one.
3. The signature has to travel through a chain of custody. When the document will be re-signed, countersigned, archived, or produced in court years later, the certificate is what lets each later reader verify the math rather than the trust.

For most internal HR, vendor, and operational documents, an ordinary electronic signature under ESIGN or UETA is enough, and adding a certificate layer costs more than it buys.

What the certificate looks like in practice is covered in Digital Certificate Example for Secure Signing Workflows, with the field-by-field read that follows.

The Traps That Make a Certificate Worthless in Court

A signature is only as good as the records around it. Five traps routinely turn a certificate-backed signature into inadmissible evidence:

1. Self-signed certificates with no trust anchor. A signature produced by a certificate the signer generated on their own laptop proves only that "my computer made this," not that "this person signed it." The court will treat it as such.
2. Expired certificates at signing time. A signing certificate has a NotBefore and NotAfter. If the document was signed outside that window, the signature is invalid even if everything else is correct.
3. Revoked certificates. A certificate on a Certificate Revocation List (CRL) or marked revoked through OCSP at the moment of signing is not a valid signing credential. The signing system has to check revocation status, not just expiry.
4. Missing or wrong Key Usage. A certificate intended for TLS or S/MIME will not produce a defensible document signature, even when the cryptographic math is correct.
5. No record of what was signed. A signature over a hash is a signature over a specific byte sequence. If the platform cannot show the exact bytes hashed, the signature cannot be verified against the document on file later.

The first three are detected by checking the certificate itself. The last two are detected by checking the system that produced the signature.

What a Signing Platform Has to Capture Around the Certificate

For an X.509-backed signature to be useful in a dispute, the signing system has to record, at the moment of signing, the certificate chain used, the hash algorithm applied, the document hash produced, and the timestamp from a trusted source. A timestamp from a TSA (Time Stamping Authority) that is anchored to the certificate is what extends the signature's evidentiary weight past the certificate's own expiry. Without it, the signature is only as durable as the certificate's NotAfter date.

The audit trail around the signature has to capture these fields in a form that can be reproduced years later, when the certificate, the CA, and the document may all live in different places. A PDF with a blue ribbon and an embedded signature is not enough; the certificate, the chain, and the timestamp must be exportable in a form a third party can verify.

How a typical signed PDF picks up the chain is the practical example in How to Sign a PDF With a Digital Signature Certificate.

How to Read a Signing Certificate Before You Trust It

When a counterparty sends a signed document, the receiving side has to verify four things:

1. Issuer: is the certificate from a CA your org's trust store recognizes?
2. Key Usage: does the certificate authorize document signatures?
3. Validity window: was the certificate valid at the time of signing?
4. Revocation status: was the certificate revoked at the time of signing?

Tools like OpenSSL's openssl x509 -in cert.pem -text -noout show the raw fields; most signing platforms expose the same information through a verification report. The check has to be runnable offline, because the document may need to be verified years after the signing CA has shut down or been distrusted.

A certificate-backed signature that survives those checks is the strongest form of document authentication the open standards support. One that does not survive them is a blue ribbon on a piece of paper.

A walk-through of the verification steps in a real workflow is in How to Check a Digital Certificate Before You Trust It.

Checklist Before You Sign With an X.509 Certificate

Use this as a pre-flight before signing or accepting a certificate-backed signature:

• Issuer: confirm the CA is on your trust list or your counterparty's trust list, not just the one that signed the document.
• Purpose: confirm Key Usage includes digitalSignature or the equivalent Extended Key Usage OID, and nothing in the certificate forbids document signing.
• Validity: confirm the signing time falls inside NotBefore and NotAfter, accounting for time zone and clock skew.
• Revocation: confirm the certificate was not on a CRL or marked revoked via OCSP at signing time.
• Hash: confirm the signing platform records the hash algorithm used and the hash value produced.
• Timestamp: confirm a TSA-issued timestamp was applied, especially if the certificate's NotAfter is close to signing time.
• Retention: confirm the platform retains the certificate chain, the document, and the audit trail in a verifiable form for at least as long as the dispute window.

What a Certificate-Verifiable Export Looks Like

The math of an X.509 signature is not the part most teams get wrong. What fails is what travels with the signature when a dispute lands years later. The platform FaDaDa ships under the name Nota Sign is built around that moment: the signed PDF, the certificate chain that was in force at signing time, the hash of the document that was actually signed, and the timestamp from a trusted source are all bundled into one export that can be verified offline.

The point is not that the cryptography is sophisticated. The point is that the next reader — a regulator, a court, your successor — does not need to call anyone to reconstruct what was on screen when the mark was applied. They take the package, run the four checks at the start of this guide, and either it holds or it does not.

If you have a signed document you want to put through those four checks, send us the package and we will report what holds up.

Disclaimer

This article describes the technical and legal mechanics of electronic and digital signatures in general terms. It is not legal advice and does not certify compliance with any statute, regulation, or industry rule. Specific obligations vary by document class, jurisdiction, and counterparty policy, and your counsel and records-management team should approve any signature workflow before it is adopted.