What is actually in a sealed PDF

When everybody has signed, Good Seal produces one PDF and sends it to every party. This is what is inside it, and how to check the claims it makes without taking our word for any of them.

1. The fields, stamped into the page

Field positions are stored normalised — coordinates from 0 to 1 with the origin at the top left, the way a browser thinks. PDF puts its origin at the bottom left, so every box is flipped at stamp time using the page's own dimensions in points, which are recorded when the file is first uploaded. That indirection is what lets the same layout work on A4 and Letter, and on a page somebody rotated before sending it.

Text is drawn into the page content, not added as an interactive form field. A filled form field is still editable and still carries its own value; stamped text is part of the page.

2. The certificate page

A final page is appended listing every party, their email address, and the moment they viewed and signed, each with the IP address and user-agent recorded at the time. It also carries the SHA-256 hash of the original uploaded bytes. If somebody produces a different 'original' later, the hash on the certificate page settles which one you were both looking at.

3. The signature

The finished file is signed as PAdES — a PKCS#7 detached signature embedded in the PDF's signature dictionary, covering a byte range that spans the entire document except the hole the signature itself sits in. Change one byte anywhere else and the digest no longer matches.

The important word is detached. The signature is computed over the document's bytes and stored beside them rather than wrapping them, which is what allows a reader to open the file normally while still being able to check it.

Verifying it yourself

You do not need us, or any particular reader, to check a signature. Extract the signature and the signed byte range from the PDF, then hand both to openssl:

openssl smime -verify \
  -inform DER -in sig.der \
  -content content.bin \
  -noverify -out /dev/null

Verification successful means the bytes you have are the bytes that were signed. Flip a single byte in content.bin and run it again — it fails. That is the whole guarantee, and it is worth doing once on a document you care about, if only to see the failure case with your own eyes.

-noverify skips checking the certificate chain, which is the right flag when you want to test document integrity separately from questions of who issued the certificate. Drop it to check the chain as well.

What the signature does and does not prove

• It proves the document has not changed since it was sealed.
• It proves the sealing was done by the holder of the signing key.
• It does not, on its own, prove who the human signers were. That is what the audit trail and the email round-trip are for.

Those three sentences are the difference between a cryptographic signature and a legal one, and conflating them is the most common mistake in this field. The cryptography makes the record tamper-evident. The evidence around it — who was emailed, who opened it, from where, and when — is what identifies the people.

If no certificate is configured

The PAdES signature is optional. Without a signing certificate the audit trail, the certificate page and the stored hashes all still stand, and the document is still perfectly valid as a simple electronic signature. You lose tamper-evidence at the file level, which is worth having, and worth the ten minutes it takes to generate a certificate.