How to Digitally Sign a PDF with a Certificate (Step by Step)

What do you need before you can sign?

Three things: a PDF reader that supports certificate-based signing, a digital ID registered on the machine, and — if the signature has to mean something to a recipient — a digital ID issued by a certificate authority rather than one you generated yourself. Acrobat and the free Acrobat Reader both sign. The certificate is the part people underestimate.

A "digital ID" in Adobe's terminology is a certificate plus the private key that goes with it. Acrobat will happily create one for you in about fifteen seconds, and that generosity is the source of most of the trouble in this topic. The ID it creates is self-signed: your computer vouches for your name, and nothing else does. It signs perfectly well. It just cannot be validated by anybody who did not first agree, manually, to believe it.

Worth settling before you start: are you signing or certifying? Signing records approval and several people can sign the same file in turn. Certifying is the author's act, has to come first, and pins down what anyone may change afterwards. The steps below cover signing, which is what most people mean.

How do you sign a PDF in Adobe Acrobat?

Open the document, select All tools, choose Use a certificate, then Digitally sign. Acrobat explains that you need to drag a signature area; confirm, then drag the rectangle where the seal belongs. Pick your digital ID, review the appearance, enter the password or PIN, and save. The signature is written into the file you save, so save under a new name.

One habit worth forming early: sign the final PDF, not a draft you intend to touch up. Any later edit — even one that looks cosmetic, like flattening layers or re-saving through a different tool — changes the bytes the hash was computed over, and Acrobat will report that the document has been modified since signing. Signing has to be the last thing that happens to the file.

Why does my signature say "Signature validity is UNKNOWN"?

Because the reader cannot build a chain from your signing certificate to a root it already trusts. Adobe's validation logic asks two separate questions — is the document unchanged since signing, and is the signer's identity trustworthy — and answers them independently. A self-signed digital ID passes the first and fails the second, which produces the yellow triangle and the banner "At least one signature has problems".

That wording does a lot of damage. Recipients read "problems" and assume the document was tampered with, when the file is usually intact and the reader is simply saying it has never heard of you. Two clicks into the Signature Panel the message becomes clearer: the signer's identity is unknown because it has not been included in your list of trusted certificates.

The yellow triangle has a manual workaround: each recipient can open the signature properties, add your certificate to their trusted identities, and tick the box that says use this certificate as a trusted root. It works. It also asks every counterparty to make a security decision on your behalf, which is a hard sell to a compliance team and impossible with an audience you cannot phone.

Which certificates does Acrobat trust automatically?

Adobe states it plainly: by default, Acrobat and Reader trust signers whose certificates trace back to a certificate on the Adobe Approved Trust List, on the European Union Trusted Lists, or issued through Certified Document Services. Certificates from anywhere else — including any you generate yourself — start out untrusted, and stay that way until a human intervenes on the recipient's machine.

AATL is a vetting programme rather than a directory. A CA applies, submits to Adobe's technical requirements and audit rules, and Adobe adds its root to a list that Adobe itself signs and publishes. Acrobat 9 and later download that list on a schedule, which is why an AATL-backed signature works on a machine nobody has configured. One of those technical requirements matters when you are choosing a product: the CA must protect the private key in a medium that prevents export and duplication, so a publicly trusted document signing certificate arrives on a card, a token, or a key held in the CA's hardware security module — never as a file you can copy.

If your recipients are in Europe, the EU Trusted Lists give you a second route to the same green check, and the two overlap heavily — most European qualified providers appear on both. Certum's document signing certificate, for example, is an advanced electronic signature under eIDAS that also meets Adobe's AATL requirements, which is the combination most cross-border business documents want.

Practical takeaway when you are comparing offers: check the CA's AATL membership before you compare anything else about the product. It is the single attribute that decides whether the signature works silently or generates a support ticket from every recipient. Our document signing certificates are issued by Certum, which is an AATL member, so signatures validate in Acrobat and Reader without anyone changing a setting.

How do you keep the signature valid after the certificate expires?

Add an RFC 3161 timestamp at signing time, and embed the revocation data alongside it. The timestamp tells a future verifier which moment to judge your certificate against, so an expired certificate no longer invalidates the signature. The embedded revocation data lets that verification succeed even when the CA's responders no longer answer questions about a certificate that expired years ago. Acrobat calls the result "LTV enabled".

The ETSI PAdES baseline gives these states names, and knowing them helps when a counterparty's validation service reports back in that vocabulary. B-B is the bare signature. B-T adds the timestamp. B-LT adds the certificates and revocation responses needed to validate long after the fact, and B-LTA adds archival timestamps on top for documents that must outlive the cryptography itself.

Two things trip people up here. The first is that a timestamp cannot be added retroactively — the document has to be signed again, which for a countersigned contract may not be possible. The second is that Acrobat will fall back to your computer's clock without complaining if no timestamp server is configured, and the Signature Panel then shows the signing time as coming from the local machine. Nobody has to believe your laptop's clock, and for a document with legal or financial weight, nobody should.

Should you choose a cloud certificate, a card, or a token?

All three protect the key in hardware, which is what the trust programmes require, so the decision is about how you work rather than how secure each one is. A cloud certificate signs from any machine after two-factor authentication and never has to be shipped. A card or token puts the key in your pocket, which suits a single signer at one desk and becomes awkward the moment two people need to sign or somebody travels.

Either way, the identity check comes first. Expect an ID document check and, for an organizational certificate, a look at your company registration records — closer to OV validation for an SSL certificate than to buying software. Budget days rather than minutes, and start the process before the deadline that made you look this up.

Can you sign without paying for Acrobat?

Yes. The free Acrobat Reader signs with certificates through the same menu path, and it validates signatures identically, so everyone in a signing chain does not need a paid licence. The capability Reader lacks is certifying — the author's first signature that locks down permitted changes. On Linux, pdfsig from poppler-utils signs and verifies from the command line.

# Linux: list the signatures already on a PDF
pdfsig contract.pdf

# Linux: sign with a certificate from the NSS database, adding a timestamp
pdfsig -add-signature -nick "My Signing ID" \
       -sign-timestamp-server http://timestamp.example-ca.com \
       contract.pdf contract-signed.pdf

For signing inside an application rather than by hand, Apache PDFBox and iText both produce PAdES signatures and both can talk to a PKCS#11 device, which is how an invoicing system signs every document it generates. The rule that decides whether the output validates is unchanged: whatever produces the signature, the certificate behind it still has to chain to a trust list.

The same certificate also signs Office files, though Word and Excel validate against the operating system's trusted authorities rather than Adobe's lists — a difference covered in our guide to digitally signing a Word document.

One tool that does not do what its name suggests: the signature feature in macOS Preview's Markup toolbar. It pastes an image of your handwriting onto the page. No certificate is involved, no hash is computed, and nothing detects a later edit. It is fine for a delivery note and wrong for anything you would want to rely on later.

Is a digitally signed PDF legally binding?

In the EU, eIDAS recognises three levels, and the level decides how much work the signature does for you in a dispute. A simple electronic signature is any mark showing intent. An advanced signature identifies the signer and detects later changes, which is what a certificate-based PDF signature gives you. A qualified signature adds a qualified certificate and a qualified signature creation device, and Article 25 gives it the same legal effect as a handwritten signature.

Most business documents do not need the qualified level. An advanced signature from an AATL-listed CA already ties a verified identity to the file and makes any later change visible, which is what a counterparty or an auditor is usually asking about. Where a specific law names a qualified signature — certain public procurement filings, some notarial acts — nothing below it will substitute, so check the requirement before you buy rather than after.

Outside the EU the framework differs but the underlying question does not: can you show who signed, and that the document has not changed since? For the background on how the certificate carries that identity, see what a document signing certificate is and how it differs from an e-signature platform.

What do you do when the signature will not validate?

Start in the Signature Panel rather than with the banner at the top of the window. The banner is a summary; the panel names the actual failure. Nearly every case falls into one of four buckets: the signer is not trusted, the document changed after signing, the certificate had expired with no timestamp to fall back on, or the certificate was revoked. Each has a different fix and only one of them means something went wrong.

The one worth catching early is row three. A signature that validated on the day you sent it and reads as unknown eighteen months later was never wrong — it just had nothing recording when it was made. That is a documentation problem you only discover when someone reopens an old contract, which tends to be the least convenient moment available. If you are setting up signing for a team, get the timestamp server configured along with the certificate itself rather than treating it as an optional extra.

Frequently asked questions