Self-signed or independently trusted?

Cryptographic integrity vs identity trust: self-signed certificates, PKI chains, PDF validation and security considerations.

Published Sep 9, 2026 · Updated Oct 3, 2026 · 3 min read

Understanding the reader warning

Open signature properties to inspect the certificate and document integrity. A trust issue with the issuer and a modified document are different results. Do not disable security checks to hide the warning. With the demo, this warning is expected. Try the demo

TL;DR

• A PAdES signature proves PDF integrity (bytes unchanged) and binds the digest to a private key.
• The X.509 certificate carries the public key and a claimed identity. Self-signed ≠ cryptographically insecure; it means no public trust chain.
• Khatm demo and sandbox: self-signed test certificate. Production: project PKI / HSM / TSP. Khatm is not a qualified TSP.

Two distinct properties often get mixed at validation time: (1) did the document change after signing? (2) is the displayed identity anchored in a trust authority known to the validator?

Architecture model

Client application / SaaS
Khatm workflow (send, fields, PAdES, evidence)
Trust layer (certificate + private key)
Self-signed (sandbox)  |  CA / TSP / HSM (prod)
PDF validator (Adobe, etc.)

Separation of workflow (Khatm) and trust layer (PKI / HSM / TSP).

PDF bytes → ByteRange → digest (SHA-256)
                 ↓
         CMS/PKCS#7 Signature
                 ↓
         SignerCert (X.509)
                 ↓
    trust path? ──no──→ integrity OK, identity UNTRUSTED
                 │
                yes
                 ↓
         trust anchor known → identity TRUSTED

PDF viewer validation path (abstract)

Cryptographic guarantees

Regardless of certificate issuer, a valid PAdES signature establishes:

• Integrity: any change to the signed ByteRange invalidates the signature.
• Cryptographic authenticity: the digest was signed with the private key matching the certificate's public key.
• Technical non-repudiation (crypto sense): private-key possession at signing time, not automatic legal recognition.

These guarantees do not depend on Adobe marking the certificate as trusted. They depend on CMS and digest verification.

Comparison

Self-signed certificate

Issuer and Subject are identical. No intermediate CA. Useful to validate the PAdES pipeline without depending on PKI.

openssl req -x509 -newkey rsa:2048 -sha256 -days 365 \
  -keyout test-signer.key -out test-signer.crt \
  -subj "/CN=Khatm Test Signer/O=Sandbox"

# Issuer == Subject → self-signed
openssl x509 -in test-signer.crt -noout -issuer -subject

Conceptual example: test certificate (do not use in production)

Trust certificate

The certificate is issued by a CA (enterprise, local, or TSP). The private key stays under HSM, KMS, or provider control. In production, Khatm connects project by project to that layer. Khatm does not issue public trust certificates and is not a qualified trust service provider.

1. Define the required evidence level (country, industry, eIDAS / local framework).
2. Choose the issuer (customer PKI, TSP, qualified device).
3. Protect the private key (HSM/KMS, rotation, audit).
4. Validate the trust path in target viewers (Adobe trust store, enterprise policy).

Security considerations

• Never reuse a sandbox certificate/key in production.
• Separate environments: test keys outside the prod perimeter; secrets out of Git.
• Protect the signing private key (HSM/KMS, least privilege, signing-operation audit logs).
• An Adobe “unverified identity” warning is not the same as an invalid crypto signature or a tampered PDF.
• For B-T / B-LT: RFC 3161 timestamps and validation data (OCSP/CRL) per the target PAdES profile.
• Revocation: plan OCSP/CRL policy when document lifetime exceeds certificate lifetime.

General information, not legal advice. Confirm the requirements for your transaction with the appropriate adviser or receiving authority.