How to check if a PDF is signed

Someone sends you a PDF and says it is signed. There is a signature image on the last page, a date beside it, and no way to tell from looking whether any of that is worth anything.

It might be a picture of a signature dropped into a document by anybody with a PDF editor. It might be a cryptographically signed file that would fail verification the moment a single byte changed. The two look identical on screen, and separating them is a practical skill rather than a technical one. What follows is general information rather than legal advice, and what a signature needs to hold up differs by country, so check your own position before relying on it.

Three things the panel tells you

Every real check answers three separate questions, in this order.

Is there a signature at all? A drawn or scanned mark on the page is not one. A signature in the PDF sense is a dictionary inside the file with a byte range and a cryptographic blob.

Has the document changed since it was signed? ISO 32000-1 describes the procedure a conforming reader follows: verify the byte range digest first, then check that any modifications made are permitted by the transform parameters. If the digest fails, the file is not the file that was signed.

Do you trust who signed it? A separate question, and the one people misread most. The signature can verify perfectly while the certificate that produced it means nothing to your machine.

A reader that gives you a green tick is answering the first two and only sometimes the third.

Opening the signature panel, and what to do when your reader has none

In a desktop reader that validates signatures, a signed file announces itself before you go looking: a bar at the top of the document saying something about signatures, and a panel you can open to see the details entry by entry. That panel is where the values in the table below show up.

Not every viewer does this. Many render pages and never look at the signature dictionary at all, which means no message rather than a negative one. Silence is not an answer, so do not read it as one.

There are two fallbacks that always work.

The first is to look at the raw file. A PDF is mostly plain text, so on macOS or Linux you can run:

grep -a -o "/SubFilter */[A-Za-z0-9.#]*" contract.pdf
grep -a -c "/DocMDP" contract.pdf

The first command prints the signature encoding, which for a PAdES signature is /adbe.pkcs7.detached. The second counts occurrences of DocMDP, which appears in a certification signature and not in an ordinary one. Be honest about what that tells you: it proves a signature structure is present, not that it verifies. It is the difference between finding a lock on a door and finding it locked.

The second is a validator whose behaviour is documented. The European Commission publishes a demonstration validator as part of its Digital Signature Services project, which reports on the signature, the certificate chain and any timestamp against the standard validation processes. Read its own warning first: files are transmitted to the Commission’s infrastructure, and it says plainly that you should not use documents containing sensitive material. Use it on a test file, not on a client’s contract.

Certified versus signed

This is the distinction worth learning, because it changes what a valid signature actually means.

An ordinary approval signature says a person signed. A certification signature is the first signature in the document and it also declares what may be changed afterwards. ISO 32000-1 puts that declaration in a single number, P: 1 means the document is final and any change invalidates the signature, 2 permits form filling and signing, and 3 also permits annotations. The default when nothing is specified is 2.

A completed document here is certified with P set to 1. That is the strongest of the three, and it has a consequence people trip over: nothing can be appended afterwards, not even legitimately. It is why the certificate of completion, when it is included in the document rather than kept separate, has to be added before certification and never after.

The complete list of entries written into the file, and what a reader does with each, is in the table below. One line in it is worth flagging now: the certifying signature’s widget has a rectangle of zero size, so it is invisible. There is no stamp on any page to look for, and its absence tells you nothing.

Trust warnings and a self-issued certificate

Expect a warning about the signer’s identity, and understand what it is saying.

Validation has two independent parts. Cryptographic integrity asks whether the digest still matches, and it is a yes or no. Trust asks whether the certificate that signed it chains back to a root your reader already accepts, and that depends entirely on which trust list your machine happens to carry.

A certificate issued by a platform rather than by a public certificate authority in your reader’s trust store will produce an identity warning every time, on a file that is otherwise perfectly intact. That is the honest position and it is worth stating plainly rather than hiding: the signature proves the document has not changed since certification, and it does not by itself prove who the certifier is to a stranger’s software. If you need trust as well as integrity, that is what a qualified certificate under eIDAS is for, and it is a different service. What PAdES is covers where those levels sit.

Timestamps

RFC 3161 describes a timestamp authority that binds a hash of some data to a moment in time and signs the pair, giving proof that the data existed before that moment. In a PDF the token rides along as an unsigned attribute on the signature, object identifier 1.2.840.113549.1.9.16.2.14.

It matters most for the long run. Without one, a signature’s validity depends on the signing certificate still being current when someone checks; with one, a third party has attested that the signature existed while the certificate was good.

The signing service can attach one, and it grows the reserved signature space from 8192 to 24576 bytes to make room. It is not enabled: the timestamp authority URL is empty in the deployed configuration, so signed files carry no token today. The RFC 3161 explainer has the longer version.

What the certificate of completion adds

The cryptography answers a narrow question: has this file changed. It says nothing about who signed, how they were checked, or when.

That is the job of the certificate of completion, a separate PDF listing per signer the identity method used, the signing time, the IP address recorded, the consent timestamp and version, and the document hash as it stood when that person signed. Alongside it sits a hash-chained event log. Together they answer the human questions, while the certification answers the mechanical one. If you want the evidence argument end to end, it is in are electronic signatures legally binding.

The example

The worked example below is a freelance contract, which is the sort of file that most often turns up as an attachment with someone’s name typed at the bottom and nothing behind it. Run the two commands above on the next one you receive. It takes ten seconds and tells you which of the two kinds of document you are holding.