SnapPDFSnapPDF
← All posts
GUIDE · 2026-03-23 · 6 min read

X.509 certificates and e-signatures — the plain-English version

X.509 is the certificate standard behind every digital signature, TLS connection, and e-passport. Here's how it works, why it matters, and what SignBolt does with yours.

Every digital signature — including every SignBolt signature — is built on X.509 certificates. Here's what that actually means.

What an X.509 certificate is

An X.509 certificate is a structured file that contains:

  • Subject — who this certificate represents (a person, organization, or domain)
  • Public key — the mathematical key used to verify signatures (the private key stays with the subject and is never shared)
  • Issuer — which Certificate Authority (CA) signed this certificate
  • Validity period — when the certificate is valid (start date and expiry)
  • Signature — the CA's cryptographic signature over everything above, proving the CA vouches for this certificate

Why "X.509"

The name comes from ITU-T Recommendation X.509, published in 1988. It's the same standard used for:

  • HTTPS/TLS (the padlock in your browser)
  • Email signing (S/MIME)
  • VPN authentication
  • Smartcard login
  • E-passports
  • Code signing

One standard, many applications. The math doesn't change.

The chain of trust

An X.509 certificate is only trustworthy if its issuer is trustworthy. That creates a chain:

1. Root CA (self-signed, stored in your OS/browser's trust store) 2. Intermediate CA (signed by root, used for operational issuance) 3. Signer certificate (signed by intermediate, identifies the actual signer)

When validating a signature, software walks the chain up to a root it trusts. If every step verifies and no certificate in the chain is revoked, the signature is trusted.

How SignBolt manages certificates

When you sign a document on SignBolt, here's what happens:

1. SignBolt verifies your email address (entry-level identity proof) 2. Optionally verifies your government ID via a partner (stronger proof) 3. Issues an X.509 certificate bound to your email and optional identity attributes 4. Uses that certificate to produce the PAdES signature on the document 5. Embeds the certificate + signature + revocation status into the signed PDF

Certificate revocation

Every certificate can be revoked before expiry — if you lose your device, leave your company, or the CA suspects compromise. Validators check revocation status via:

  • OCSP (Online Certificate Status Protocol) — real-time query to the CA
  • CRL (Certificate Revocation List) — periodic signed list of revoked certificates

For long-term signature validity, revocation status must be captured at signing time and embedded in the signature (this is what PAdES-B-LT does).

The certificate lifetime problem

Signer certificates typically expire in 1–3 years. A signed document outlives the certificate that signed it by decades. Solution:

  • Signing timestamp (from a TSA) proves the signature existed before the certificate expired
  • Periodic archive timestamps (PAdES-B-LTA) refresh the proof indefinitely

Why this matters to you

If you're signing business contracts today, your signatures are built on X.509 certificates you don't have to manage. SignBolt handles the CA infrastructure, certificate issuance, revocation, and lifecycle. You see an email with a "Sign here" button; the X.509 machinery happens invisibly.

Next

TRY SNAPPDF

Free, no signup, 5 ops per day.

All 6 tools, 25 MB files, zero ads. Go Pro for 100 MB + batches + unlimited.

Open tools