A Guide to Verifying Digital Signatures and Understanding the Chain of Trust

Digital signatures provide authenticity, integrity, and non-repudiation for electronic documents. While many applications like Adobe Acrobat Reader validate signatures automatically, understanding the underlying process is crucial for developers and security professionals. This guide explains the core concepts of Public Key Infrastructure (PKI) and provides a step-by-step walkthrough for verifying a signed PDF using common command-line tools.

Fundamental Components of PKI

At the heart of digital signatures are two key file types: certificates and certificate revocation lists.

• .cer (Certificate File): A .cer file typically contains an X.509 digital certificate. This certificate acts like a digital passport, binding a public key to an identity, such as a person, organization, or domain. It is issued by a trusted entity known as a Certificate Authority (CA). Certificates can be encoded in binary (DER) or Base64 text (PEM) formats.
• .crl (Certificate Revocation List): A .crl file is a blacklist published by a CA. It lists the serial numbers of certificates that are no longer valid, even if their expiration date has not passed. A certificate may be revoked for various reasons, such as a compromised private key or the owner leaving an organization.

The Core of Digital Trust: The Certificate Chain

Trust in the digital world is not absolute; it is inherited. This is managed through a “Chain of Trust.”

The hierarchy consists of three main levels:

1. Root CA Certificate: This is the ultimate “trust anchor” and the starting point for trust. A root certificate is self-signed, meaning it is signed by its own private key. Operating systems and browsers maintain a “trust store,” which is a pre-installed list of these trusted root certificates.
2. Intermediate CA Certificate(s): To enhance security, Root CA keys are kept highly secure, often offline. The Root CA delegates the authority to issue certificates to Intermediate CAs.
3. End-Entity/Leaf Certificate: This is the certificate issued to the end-user, such as a website, a person for signing documents, or an organization.

Each certificate in the chain is digitally signed by the one above it. When a certificate is verified, a system follows this chain up from the leaf certificate, checking the signature at each step using the public key of the parent certificate, until it reaches a root certificate that exists in its trusted store.

A Practical Guide: Verifying a Signed PDF on Linux

Verifying a signed PDF involves three goals: confirming the document’s integrity, the signer’s authenticity, and the certificate’s validity (i.e., it hasn’t been revoked).

Required Tools:

• openssl: A robust cryptography toolkit for inspecting certificates and verifying chains.
• pdfsig: A utility from the poppler-utils package used to inspect signatures and extract data from PDFs.

Step 1: Check Integrity and Extract Signature Data

First, inspect the PDF to see signature details and confirm the document has not been modified since signing.

pdfsig your_signed_document.pdf

Next, extract the raw signature data from the PDF. The -dump option creates a file containing a PKCS#7 signature blob, which is a container for the signature and certificates—not a certificate file itself.

pdfsig -dump your_signed_document.pdf
# This creates a file like your_signed_document.pdf.sig0

Step 2: Extract Certificates from the Signature Blob

Use openssl to parse the PKCS#7 blob and extract the X.509 certificates within it, including the signer’s certificate and any embedded intermediate certificates.

# The '-inform DER' flag is needed as the blob is in binary DER format
openssl pkcs7 -in your_signed_document.pdf.sig0 -inform DER -print_certs -out signer_and_chain.pem

You can now save the primary signer’s certificate from signer_and_chain.pem into its own file, e.g., signer.cer.

Step 3: Verify the Certificate Chain

The main challenge in verification is building the complete chain to a trusted root.

1. Initial Verification Attempt: Start by trying to verify the signer’s certificate against the known Root CA certificate.

   openssl verify -CAfile rootCA.cer signer.cer
2. Troubleshooting Missing Intermediates: A common failure is the error 20 at 0 depth lookup: unable to get local issuer certificate. This means the signer’s certificate was not issued directly by the root, and an intermediate certificate is missing.
3. Finding the Issuer: To find the missing certificate, first identify the issuer of the current certificate:

   openssl x509 -in signer.cer -noout -issuer
   Modern certificates often contain an Authority Information Access (AIA) extension, which provides a URL where the issuer’s certificate can be downloaded. While graphical viewers like Adobe Acrobat often fetch these automatically, with OpenSSL this must be done manually.
4. Building the Full Chain: Once all intermediate certificates are downloaded, provide them to the verify command using one or more -untrusted flags. The command will build a chain from the signer’s certificate through the untrusted intermediates to the trusted root CA.

   # Provide all intermediates in the chain
   openssl verify -CAfile rootCA.cer \
     -untrusted intermediate_level1.cer \
     -untrusted intermediate_level2.cer \
     signer.cer
   A successful validation will return: signer.cer: OK.

Understanding Revocation Checks

A cryptographically valid chain is not sufficient; you must also check if the certificate has been revoked.

Method 1: CRL (Certificate Revocation List)

A CRL check involves verifying the certificate against the CA’s published list of revoked certificates.

# First, convert the CRL from DER to PEM if necessary
openssl crl -inform DER -in revocation_list.crl -out revocation_list.pem

# Then, perform the check
openssl verify -crl_check -CAfile rootCA.cer -untrusted intermediates.cer -CRLfile revocation_list.pem signer.cer

Method 2: OCSP (Online Certificate Status Protocol)

OCSP provides a real-time method for checking a certificate’s status by querying a CA’s “OCSP responder” server. The server responds with good, revoked, or unknown.

Crucially, the OCSP response is itself digitally signed and must be verified. You must provide the necessary intermediate certificate (via the -VAfile flag) for OpenSSL to verify the responder’s signature.

openssl ocsp \
   -issuer issuer_cert.cer \
   -cert signer.cer \
   -url [http://ocsp.server.com](http://ocsp.server.com) \
   -CAfile rootCA.cer \
   -VAfile intermediate_for_ocsp_responder.cer

A fully successful check will yield Response verify OK and signer.cer: good. OCSP only confirms revocation status; it does not replace the need for chain validation.

The Cryptography Explained: Signing vs. Verification

• The Signing Process:

  1. A cryptographic hash (e.g., SHA-256) of the document’s content is calculated.
  2. This hash is then signed (a mathematical operation, often misstated as encryption) using the signer’s private key.
  3. This digital signature, along with the signer’s certificate (which contains their public key), is embedded into the document.

• The Verification Process:

  1. The verifier extracts the signer’s certificate and first validates its chain of trust.
  2. It independently recalculates the hash of the document’s content.
  3. Using the public key from the now-trusted certificate, it verifies the signature against the independently calculated hash.
  4. If the hashes match, it proves the document’s integrity—it has not changed since being signed. The validated certificate proves the signer’s authenticity.