Audit trails + verification

How to verify a Pacta-signed PDF, what's in the embedded audit trail, and how to prove a signature is valid without contacting Pacta.

Last updated May 12, 2026

A Pacta signature isn’t worth much if no one can verify it. The good news: Pacta signatures are self-verifying. Everything needed to prove the signature is valid lives inside the signed PDF itself. You don’t need to contact Pacta, log into our service, or trust us in any way.

This article walks through how to verify, what’s actually in the audit trail, and what to do when verification gets weird.

The shortest way to verify

Open the signed PDF in Adobe Acrobat Reader.

If the signature is valid and the document hasn’t been tampered with, you’ll see a green banner at the top:

✓ Signed and all signatures are valid.

If anything’s wrong — the signature is invalid, the document was edited after signing, the certificate chain doesn’t validate — Adobe shows a red warning. No interpretation needed; if Adobe says green, it’s good.

This works in any standards-compliant PDF viewer: Adobe Reader, Adobe Acrobat Pro, Foxit, qpdf, pdfsig (Linux), most browser PDF viewers (though with limited UI). The signature is in the file regardless of viewer.

What you can verify from the PDF alone

Without contacting Pacta, anyone with the signed PDF can independently verify:

  • The PDF hasn’t been modified since signing (cryptographic integrity)
  • Who signed each part of the document (identity via embedded certificate)
  • When they signed (precise UTC timestamp from independent TSA)
  • The signature is from a valid certificate (chain-of-trust validation)
  • The certificate wasn’t revoked at signing time (OCSP / CRL data embedded)

This is the Long-Term Validation (LTV) layer in action — all the material needed to verify is inside the PDF, not on Pacta’s servers.

The certificate page

Every Pacta-signed PDF ends with a certificate page that summarizes the audit trail in human-readable form:

PACTA SIGNING CERTIFICATE
─────────────────────────

Document:    Master Services Agreement.pdf
Envelope ID: env_a1b2c3d4e5f6
Document hash (SHA-256):
             d3a9f8...c2b4
TSA token:   Certum TSA (https://time.certum.pl)
             Issued 2026-05-12T17:42:18Z

Signers
─────────────────────────
1. John Doe          john@acme.com
   IP:     173.94.x.x
   UA:     Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ...
   Viewed: 2026-05-12T17:38:02Z
   Signed: 2026-05-12T17:41:55Z

2. Jane Smith        jane@northwind.com
   IP:     78.21.x.x
   UA:     Mozilla/5.0 (X11; Linux x86_64) ...
   Viewed: 2026-05-12T17:39:14Z
   Signed: 2026-05-12T17:45:30Z

Verification
─────────────────────────
This document was signed using Pacta's eIDAS Advanced Electronic
Signature (AES) infrastructure. The cryptographic envelope (CAdES
PKCS#7) is embedded in this PDF. Long-Term Validation material is
attached for verification at any future date.

To verify:
- Open this PDF in Adobe Acrobat Reader.
- Or use any standards-compliant PDF verifier supporting PAdES /
  CAdES-LT signatures.
- Or visit https://sign.pacta.ink/verify and upload this PDF.

The page is auto-generated; no manual entry, no edits. What it shows matches what’s mathematically encoded in the signature envelope.

The page-by-page footer

Every page of a Pacta-signed PDF (not just the certificate page) carries a small footer at the bottom:

Verified by sign.pacta.ink · Envelope env_a1b2c3d4e5f6 · Signed 2026-05-12 17:42 UTC

This is a visual reinforcement, not the cryptographic proof. It’s there so that:

  • Anyone glancing at any page knows they’re looking at a signed doc
  • Screenshots of a single page still carry the envelope ID
  • Printed copies (yes, people still print) show the same provenance

The cryptographic proof is the embedded CAdES envelope, not the footer. But the footer makes the provenance obvious at a glance.

Verifying programmatically

For higher-volume verification or building your own verification UI, parse the PDF directly. The signature is in the PDF’s /Sig dictionary; tools that can read it:

Command line (Linux / macOS)

# Show signature info
pdfsig signed-contract.pdf

# Output:
# Signature #1:
#   - Signer Certificate Common Name: Pacta Signing CA
#   - Signer full Distinguished Name: ...
#   - Signing Time: May 12 2026 17:42:18
#   - Signing Hash Algorithm: SHA-256
#   - Signature Type: ETSI.CAdES.detached
#   - Signature Validation: Signature is Valid.
#   - Certificate Validation: Certificate issuer isn't Trusted.

The “Certificate issuer isn’t Trusted” warning is normal — pdfsig doesn’t have Pacta’s CA in its default trust store. The signature itself is valid; you’d add Pacta’s CA cert to your trust store for clean validation.

Java / Node.js

Use Apache PDFBox (Java) or pdf-lib (Node) to extract the /Sig dictionary and the embedded CAdES envelope. Then validate the PKCS#7 structure against your trust anchors.

Browser

The EU DSS Demonstration Tool accepts PDF uploads and validates against the EU Trust List. Drop a Pacta-signed PDF in — you’ll see a full report of every signature, every TSA token, and every certificate in the chain.

Verifying via Pacta’s verify endpoint

For convenience (not necessity), Pacta hosts a verification page at https://sign.pacta.ink/verify. Upload a PDF and it shows:

  • A green “Valid” or red “Invalid / Tampered” verdict
  • The full audit trail (same data as the certificate page)
  • The TSA token + Pacta’s signing certificate chain
  • The hash of the PDF + verification of the embedded CAdES envelope

This endpoint doesn’t need you to be logged in. Anyone can verify a Pacta-signed PDF. The result is deterministic — if the embedded signature is valid, anyone who runs the same check gets the same answer.

When verification fails

Common failure cases:

“Signature is invalid / document has been modified”

Someone changed the PDF after signing. Even something as innocent as “re-saving in Adobe Acrobat Pro with no edits” can sometimes break the signature if Acrobat rewrites the file structure. The signature is intentionally strict — if a byte changed, the signature is invalid.

What to do: ask the sender for the original signed PDF. Don’t trust the modified one.

”Certificate chain is incomplete / untrusted”

The verifier doesn’t have Pacta’s CA in its trust store. The signature itself is mathematically valid; the verifier just doesn’t know it should trust the CA.

What to do: add Pacta’s CA certificate (downloadable from sign.pacta.ink/certificate-authority — planned route, not live yet) to your verifier’s trust store, or use the EU DSS Tool which auto-validates against the EU Trust List.

”Timestamp is invalid / outside the validity period”

The TSA token couldn’t be verified. This is rare but happens if either (a) the TSA’s signing certificate has been revoked or (b) the PDF’s LTV material got stripped.

What to do: if you have the original PDF (not a re-save), the LTV should still validate. If the LTV got stripped (e.g., someone re-saved in a tool that doesn’t preserve signature material), get the original from the sender.

Audit trails inside the app

Beyond the embedded certificate, every Pacta envelope has a more detailed audit log visible to the sender in-app:

Documents → click the envelope → Audit Logs tab

This log records every event:

  • Recipient opened the email
  • Recipient viewed the PDF
  • Recipient updated a field
  • Recipient signed
  • System auto-inserted timestamps
  • Sender resent the email
  • Sender cancelled / modified the envelope

Each event has timestamp, IP, user agent, and (where relevant) the field or signer involved. This is more granular than the certificate page in the final PDF — useful for debugging “why didn’t the signing complete?” but the final PDF carries everything you need for legal purposes.

The in-app audit log is also downloadable as PDF or CSV.

Where to go next

Have a question this doc didn't answer? Email us and we'll fix it.