How to verify a sealed PDF

What verification actually checks

Verification does not read the document to judge whether its contents are correct. It checks whether the file you hold is the same file recorded at sealing time. Three things are compared, and each answers a different question.

For a sealed file, the package hash is the fingerprint of the whole PDF, including the certificate inside it. That hash is stored in the seal record rather than in the certificate, because adding the certificate to the package would change the package hash itself.

Checking with the verification link

Every sealed record has a permanent verification link. It opens without an account and without access to the issuing organisation's systems. The verification page shows the organisation, the document number, the approvers, the sealing time, and the technical values behind the record.

1. Open the verification link printed on the certificate or sent with the document.
2. Check the organisation name, document number, and approver list on that page.
3. Download the sealed file from the original source, not from a forwarded attachment.
4. Upload that file to the verification page so its hash can be compared.
5. Read the result: a match means the file is the same, a mismatch means it differs.

Checking without the link

If all you hold is the file, open the first page. It carries the certificate of approval with the document hash, the audit root, a timestamp label, and the verification address. Those values are the starting point for a check, not the final proof.

For a manual check, compute the SHA-256 of the file you hold with a command-line tool, then compare it with the package hash shown on the seal record. On Linux and macOS the command is simple.

1. Run shasum -a 256 file-name.pdf on macOS, or sha256sum file-name.pdf on Linux.
2. Copy the resulting hash and compare it with the package hash on the seal record.
3. If the values match exactly, the file is the package that was sealed.

Remember that the package hash can only be compared with the seal record, not with a value printed inside the certificate. The certificate carries the document hash and the audit root. The package hash lives outside the file, in the seal record and on the verification page.

Reading a mismatch

A mismatch does not mean the document is fake, and it does not mean the approval never happened. Only one conclusion follows: the file you checked is not the file that matches the seal record. There are several possible causes.

• The file was edited after sealing, for example an amount or vendor name was changed.
• The file was reprinted or reprocessed by another application, changing its bytes.
• The file you uploaded is the draft, not the approved version.
• The file belongs to another record with a similar document number.

A mismatch is therefore best followed up by requesting the original file from the issuing source. Do not rely on a copy that has passed through many hands.

What verification does not prove

Verification proves file integrity and history, not the truth of the contents. A sealed document may still contain a wrong figure, be approved by the wrong person, or rest on inaccurate source data. The seal does not judge that.

Verification also does not make a document automatically valid under any particular law. The precise claim is this: the record is tamper-evident, so changes become visible, and it is independently verifiable, so the check does not depend on the issuer's word.

Habits that make verification useful

Verification only helps when it happens at the right moment. A few habits make it part of ordinary work.

• Check a file when it arrives, not only when a problem appears later.
• Keep the verification link with the file, because the link does not depend on the plan or the archive.
• Record the result when the document supports a significant decision.
• Request the file from its original source when the check fails, rather than trusting a copy.

For teams that regularly receive documents from outside, this check can become part of document intake. One short check at the start prevents a long argument later.