Digital Certificates and PKI for PDF Signing

← Back to Blog

What Is a Digital Certificate?

A digital certificate is a structured data file that binds a public key to an identity — a person, organisation, or device. When you digitally sign a PDF, the signature is created using your private key and verified using the corresponding public key published in your certificate. The certificate answers the question: "Whose private key created this signature?" It does so by having a trusted third party — a certificate authority — vouch for the binding between the key and the identity.

The dominant standard for digital certificates is X.509, originally defined by the ITU-T and adopted widely across the internet and PKI ecosystems. PDF digital signatures rely on X.509 certificates, and Adobe Acrobat's signature validation is built around the X.509 trust model.

Key Components of an X.509 Certificate

An X.509 certificate contains a set of fields that together define the identity and scope of the certificate:

• Subject Distinguished Name (DN): A structured identifier for the entity the certificate belongs to — typically including Common Name (CN), Organisation (O), Organisational Unit (OU), Country (C), and sometimes email address. For a document signing certificate, the CN is usually an individual's name or an organisation's name.
• Public key: The certificate's primary payload. It contains the public key (RSA, ECDSA, or another algorithm) that corresponds to the private key held by the certificate owner.
• Issuer DN: Identifies the certificate authority that signed and issued this certificate.
• Validity period: Two fields — Not Before and Not After — define the window during which the certificate is considered valid. Adobe Acrobat checks the signing time against this window during validation.
• Serial number: A value unique within the issuing CA, used to identify this specific certificate, particularly in revocation checking.
• Signature algorithm: Identifies the algorithm the CA used to sign the certificate (e.g., SHA-256 with RSA).
• Extensions: X.509 v3 extensions add richer information, including Key Usage (which cryptographic operations the key may be used for), Extended Key Usage (specific purposes such as document signing or email protection), Subject Alternative Names, and Basic Constraints (whether the certificate can itself issue certificates).

Certificate Authorities and the Trust Hierarchy

A certificate authority (CA) is an entity that issues certificates after verifying the applicant's identity. The trust model is hierarchical: at the top sits a root CA, whose certificate is self-signed and distributed with operating systems and applications (including Adobe's Approved Trust List, or AATL). Below root CAs are intermediate CAs, which hold certificates issued by the root. End-entity certificates — the ones used for actual signing — are issued by intermediate CAs.

This chain structure has practical benefits: root CA private keys can be kept offline in highly secured facilities, intermediate CAs handle day-to-day issuance, and if an intermediate CA is compromised it can be revoked without invalidating the root. When Adobe Acrobat validates a PDF signature, it builds a chain from the signing certificate up through any intermediates to a trusted root, checking that each certificate in the chain is valid, not revoked, and correctly signed by its issuer.

Self-Signed vs. CA-Issued Certificates

A self-signed certificate is one where the issuer and subject are the same — the certificate is signed by its own private key rather than by a CA. Self-signed certificates are free and easy to generate (tools like OpenSSL can create one in seconds), but they have a fundamental limitation: no one else will automatically trust them. When a recipient opens a PDF signed with a self-signed certificate, Acrobat will display a warning that the signer's identity cannot be verified, because the certificate does not chain to any trusted root.

For PDF signatures intended to convey trust to external parties — customers, partners, regulators — a certificate issued by a publicly trusted CA is required. Adobe maintains the AATL, a list of CAs whose root certificates are trusted by Acrobat and Adobe Reader by default. A signature from an AATL-trusted certificate shows a blue ribbon in Acrobat without requiring any manual trust configuration.

Obtaining a Document Signing Certificate

Commercial certificate authorities offer document signing (or code signing) certificates as a paid product. The major providers include DigiCert, GlobalSign, Sectigo (formerly Comodo CA), and Entrust. The validation level varies:

• Individual validation: The CA verifies the applicant's identity against government-issued ID. Suitable for personal document signing.
• Organisation validation (OV): The CA verifies both the individual and the organisation they represent. The organisation name appears in the certificate's Subject DN.
• Extended validation (EV): The most rigorous identity check, typically used for code signing; the CA follows strict guidelines before issuance.

Free certificate options exist — Let's Encrypt issues TLS certificates trusted by browsers, but not document signing certificates. Some CAs offer trial or low-assurance personal certificates, but these are typically not included in the AATL and will not produce trusted signatures in Acrobat by default.

Importing Certificates into Acrobat

Once you have obtained a signing certificate (typically delivered as a PKCS#12 .p12 or .pfx file containing both the certificate and private key), you import it into Acrobat via Edit > Preferences > Signatures > Identities & Trusted Certificates. Acrobat can also use certificates stored in the Windows Certificate Store or macOS Keychain. After import, the certificate appears in the list of digital IDs and can be selected when applying a signature field.

Certificate Security vs. Password Security

It is worth distinguishing between using a certificate to sign a PDF (asserting authorship and integrity) and using a certificate to encrypt a PDF (controlling who can open it). Certificate-based encryption allows you to encrypt a document for specific named recipients, each identified by their X.509 certificate, so that only holders of the corresponding private keys can decrypt and open the file — no shared password is needed. This is a more sophisticated model than password protection but requires that the author has access to each recipient's public certificate before sending.