Verify an AcreSeal record yourself — without our cooperation

Fetch the record

Replace <record-id> with the UUID you were given.

curl -s "https://acreseal.com/api/verify-chain?id=<record-id>&verify_env=true" -o record.json
jq '.valid, .authoritative, .broken_at' record.json

Expect valid: true, authoritative: true, and broken_at: null.

authoritative is a property of the record, not of its id. Demonstration records — including, but not limited to, any id beginning demo- — return authoritative: false with demo: true. A record whose status could not be established returns authoritative: false with demo: false, and names the reason in authoritative_reason: absent is not the same as illustrative. Treat only authoritative: true as evidence.

Reproduce the photo hash

Download the stored evidence photo and hash it. This is the load-bearing check.

curl -s "$(jq -r '.photo.url' record.json)" -o evidence.jpg
shasum -a 256 evidence.jpg
jq -r '.photo.serverSha256' record.json

The two values must be identical.

Recompute the environmental hash

The record's forensic_hash binds the capture time, coordinates, weather at that place and hour, and the photo hash into one digest. The raw inputs are published so you can recompute it rather than trust our answer.

jq -r '[.env_context.timestamp, .env_context.lat, .env_context.lng,
        .env_context.temp, .env_context.wind, .env_context.cloud,
        .env_context.photoHash] | join("|")' record.json | tr -d '\n' | shasum -a 256

jq -r '.env_verification.stored' record.json

The fields are joined with | in exactly that order, with no spaces, and SHA-256'd. Absent values appear as the literal string null. Numeric fields are fixed-precision strings as published — do not re-round them.

Walk the hash chain

Each audit entry embeds the previous entry's hash, so any edit to history breaks every link after it.

jq '.entries[] | {action, forensic_hash, previous_hash, chain_valid}' record.json

Every entry should report chain_valid: true, and broken_at at the top level should be null. Immutability is enforced by database triggers, not by application code.

Optionally, read the photo metadata

Corroborating only — never treat EXIF as the integrity anchor.

exiftool evidence.jpg

You will see Software: AcreSeal Forensic Pipeline v1.0 and an AcreSeal provenance block. Original camera tags are carried forward when the file had them, but many will not: mobile operating systems strip metadata from photos captured through a browser, and files above 2 MB are re-encoded during compression. A record with no camera EXIF is normal and does not weaken the hash evidence.

Read the inclusion block

curl -s "https://acreseal.com/api/verify-chain?id=<record-id>" -o record.json
jq '.inclusion | {status, leaf_index, leaf_count, merkle_root_hash, job_id}' record.json

A status of proven means a proof is supplied. not_sealed means the record was never sealed into a job, so no third-party timestamp covers it. leaf_absent means the seal does not cover this record.

unverified is different in kind from all of those. Each of them is a finding about the record; this one means the check did not run, because an input could not be read on our side. It is not evidence that the record is unsealed — treat it as an absent answer, retry, and if it persists verify the job seal directly with the job_id the response still returns.

Fold the proof yourself

Hash the record's forensic hash as an RFC 6962 leaf, then fold in each sibling. An odd node at any level is promoted unchanged — not duplicated as in Bitcoin — which is why a tree of n leaves may contribute fewer than log₂(n) steps.

node -e '
const { createHash } = require("crypto");
const inc = JSON.parse(require("fs").readFileSync("record.json")).inclusion;
const sha = (b) => createHash("sha256").update(b).digest();
let h = sha(Buffer.concat([Buffer.from([0x00]), Buffer.from(inc.leaf_hash, "hex")]));
for (const s of inc.proof) {
  const sib = Buffer.from(s.hash, "hex");
  h = s.position === "left"
    ? sha(Buffer.concat([Buffer.from([0x01]), sib, h]))
    : sha(Buffer.concat([Buffer.from([0x01]), h, sib]));
}
console.log(h.toString("hex") === inc.merkle_root_hash ? "INCLUDED" : "NOT INCLUDED");
'

INCLUDED means the record is provably one of the leaves under merkle_root_hash. Carry that root into Part 3 to establish its place in third-party time.

Fetch the seal

curl -s "https://acreseal.com/api/verify-seal?job_id=<job-id>" -o seal.json
jq '{root_matches, signature_valid, trusted_timestamp_present, leaf_count: .seal.leaf_count}' seal.json

root_matches and signature_valid are our computations. The remaining steps let you reproduce them yourself, which is the point.

Either may be null, and null is not false. It means we did not compute the value, not that the check failed — verification_status says which: read_failed if an input could not be read, malformed_leaf if a stored leaf is not a 64-character hex digest. When it is read_failed, leaves is null rather than an empty list, because an empty list would be a false answer to "which records does this seal cover". Step 2 onward is unaffected: you can still recompute everything yourself whenever the leaves are present.

Recompute the Merkle root

The response returns leaves — the ordered per-record hashes. Rebuild the root from them using RFC 6962 rules:

• leaf hash = SHA256(0x00 || leaf_bytes)
• internal node = SHA256(0x01 || left || right)
• an odd node at any level is promoted unchanged to the next level
• leaves are the 64-character hex strings decoded to raw bytes, in the order given

Note the odd-node rule: AcreSeal promotes, it does not duplicate the last leaf. A Bitcoin-style implementation will produce a different root on any set with an odd count at some level.

node -e '
const { createHash } = require("crypto");
const sha = (b) => createHash("sha256").update(b).digest();
const leaf = (h) => sha(Buffer.concat([Buffer.from([0x00]), Buffer.from(h, "hex")]));
const node = (l, r) => sha(Buffer.concat([Buffer.from([0x01]), l, r]));
const mth = (ls) => {
  if (ls.length === 1) return ls[0];
  let k = 1; while (k * 2 < ls.length) k *= 2;
  return node(mth(ls.slice(0, k)), mth(ls.slice(k)));
};
const s = JSON.parse(require("fs").readFileSync("seal.json"));
const root = mth(s.leaves.map(leaf)).toString("hex");
console.log(root);
console.log(root === s.seal.merkle_root_hash ? "ROOT MATCHES" : "ROOT DOES NOT MATCH");
'

This is the same folder used in Part 4 Step 2, reading seal.json instead of the log entries. The bullets above are the specification; this is its executable form.

Verify the Ed25519 signature

The signed message is four fields joined with pipes — job_id | merkle_root_hash | combined_sha256 | timestamp_sealed_self_asserted — and this builds it and checks it in one step. It prints the message first, so you can see exactly what is being verified:

node -e '
const { verify } = require("crypto");
const s = JSON.parse(require("fs").readFileSync("seal.json"));
const m = [s.job_id, s.seal.merkle_root_hash, s.seal.combined_sha256,
           s.seal.timestamp_sealed_self_asserted].join("|");
console.log(m);
console.log(verify(null, Buffer.from(m), s.seal.public_key,
  Buffer.from(s.seal.cryptographic_signature, "base64"))
  ? "SIGNATURE VALID" : "SIGNATURE INVALID");
'

Why node and not openssl here. macOS ships LibreSSL, which cannot load an Ed25519 public key at all — it fails with unable to load Public Key before it gets as far as the signature. If you have OpenSSL 3.x (brew install openssl, or most Linux distributions) this is the equivalent. Note jq -j, not -r: -r appends a newline and the signature then fails, the same trap as the checkpoint in Part 4.

jq -j '[.job_id, .seal.merkle_root_hash, .seal.combined_sha256,
        .seal.timestamp_sealed_self_asserted] | join("|")' seal.json > seal-msg.txt
jq -r '.seal.cryptographic_signature' seal.json | base64 -d > seal.sig
jq -r '.seal.public_key' seal.json > seal-key.pem
openssl pkeyutl -verify -pubin -inkey seal-key.pem -rawin -in seal-msg.txt -sigfile seal.sig

Verify seal.cryptographic_signature (base64) over that message using seal.public_key (SPKI PEM). Cross-check that key against the copy published independently at /.well-known/acreseal-seal-key.pem — if they differ, stop and ask why.

That cross-check is not optional, and here is precisely why. The signature is verified against seal.public_key — the key carried by the seal you are checking. So signature_valid: true tells you the signature matches the key printed beside it. It does not tell you whose key that is. Anyone who can write a seal can sign it with a keypair they generated, and it will report true exactly as this one does. The .well-known file is what closes that loop, because it is published separately from the response you are holding.

As of August 2026 the API does this comparison too and reports it as public_key_is_current_signing_key. Treat it as a convenience, not a substitute — it is still our computation, and the point of fetching the key yourself is to not have to take our word for it. A false there is not proof of forgery. We publish no archive of superseded keys, so a seal signed before a key rotation legitimately carries a key that is no longer the current one, and from the outside it looks identical to a key that was never ours. It means “not the key we sign with today” — a reason to ask, not a finding. null means no signing key is configured and the comparison did not run at all.

Use the four values exactly as the API returns them — do not reformat the timestamp. Ed25519 signs bytes, so …195Z and …195+00:00 are the same instant but different messages, and only one of them was signed. Until August 2026 this endpoint served the second form while signing the first, so anyone following these steps literally got false. The seal-creation endpoint POST /api/v1/jobs/{id}/seal kept doing so for longer, and was corrected separately; every route now publishes the exact string that was signed, and both timestamp_sealed and timestamp_sealed_self_asserted carry it. If you are checking against a response you captured before then, that is the discrepancy.

signature_valid: null means the seal carries no signature at all, which is different from false. Some early seals are unsigned.

Verify the trusted timestamp

This is the step that establishes time independently of AcreSeal. The token is a complete RFC 3161 response, verifiable with OpenSSL alone.

jq -r '.trusted_timestamps[0].token_base64' seal.json | base64 -d > token.tsr
ROOT=$(jq -r '.seal.merkle_root_hash' seal.json)

# Obtain the CA chain for the authority named in trusted_timestamps[n].tsa_url.
# The token embeds the TSA's signing certificate and intermediates (certReq is
# set on every request), so only the ROOT certificate must come from you:
#   DigiCert: https://www.digicert.com/kb/digicert-root-certificates.htm
#   Sectigo:  https://www.sectigo.com/resource-library/sectigo-root-intermediate-certificate-files
curl -sO <root certificate URL from the authority's page>   # -> tsa-root.pem
openssl ts -verify -digest "$ROOT" -in token.tsr -CAfile tsa-root.pem

# Read the TSA's stated time:
openssl ts -reply -in token.tsr -text | grep "Time stamp:"

Expect Verification: OK. Verifying against the authority's own root — rather than a whole system trust store — proves the token chains to the TSA it claims, not merely to some trusted CA. For a self-signed service such as freetsa.org, its site publishes the CA to use.

Fetch and verify a checkpoint

curl -s "https://acreseal.com/api/transparency/checkpoint" -o checkpoint.json
jq '{tree_size, root_hash, signature_algorithm}' checkpoint.json

# Verify the signature over the EXACT signed bytes.
# jq -j, not -r: -r appends a newline and the signature then fails.
jq -j .body checkpoint.json > checkpoint.txt
jq -r .signature checkpoint.json | base64 -d > checkpoint.sig
curl -s https://acreseal.com/.well-known/acreseal-seal-key.pem -o seal-key.pem
openssl pkeyutl -verify -pubin -inkey seal-key.pem -rawin -in checkpoint.txt -sigfile checkpoint.sig

That needs OpenSSL 3.x. On stock macOS (LibreSSL) it fails with unable to load Public Key, so use this instead — it also sidesteps the newline trap entirely, because no file is written:

node -e '
const { verify } = require("crypto");
const c = JSON.parse(require("fs").readFileSync("checkpoint.json"));
const pem = require("fs").readFileSync("seal-key.pem", "utf8");
console.log(verify(null, Buffer.from(c.body), pem, Buffer.from(c.signature, "base64"))
  ? "CHECKPOINT SIGNATURE VALID" : "CHECKPOINT SIGNATURE INVALID");
'

Expect Signature Verified Successfully. Verify against body as returned — do not rebuild it from tree_size and root_hash. Checking what was actually signed is the point.

Rebuild the root yourself

The log publishes its leaves for the same reason a seal does: without them you would be trusting our arithmetic.

curl -s "https://acreseal.com/api/transparency/entries" -o entries.json
jq '{tree_size, count: (.leaves | length)}' entries.json

node -e '
const { createHash } = require("crypto");
const sha = (b) => createHash("sha256").update(b).digest();
const leaf = (h) => sha(Buffer.concat([Buffer.from([0x00]), Buffer.from(h, "hex")]));
const node = (l, r) => sha(Buffer.concat([Buffer.from([0x01]), l, r]));
const mth = (ls) => {
  if (ls.length === 1) return ls[0];
  let k = 1; while (k * 2 < ls.length) k *= 2;
  return node(mth(ls.slice(0, k)), mth(ls.slice(k)));
};
const { leaves } = JSON.parse(require("fs").readFileSync("entries.json"));
console.log(mth(leaves.map(leaf)).toString("hex"));
'

The printed root must equal root_hash from the checkpoint you just verified.

Prove the log only ever appended

This is the check the log exists for, and it needs a checkpoint you saved earlier. Keep the ones you are given.

curl -s "https://acreseal.com/api/transparency/consistency?first=<old size>&second=<new size>"

We do not publish a one-command recipe for this step yet. The proof is served by the endpoint above and the verification is RFC 6962 consistency verification, taking both sizes and roots from signed checkpoints — but reducing it to a single shell command we have actually run is work we have not done. Saying so is better than printing a command that does not verify what it claims to. Two properties are worth knowing precisely:

• The proof binds the two roots to each other. It does not bind a size to a root — that binding comes from the checkpoint signature, which is why step 1 comes first.
• A consistency proof does not by itself reveal entries dropped after the prefix it proves. Compare checkpoint sizes: a size that goes backwards is the signal.

Check the checkpoint's trusted timestamp

jq -r '.trusted_timestamps[0].token_base64' checkpoint.json | base64 -d > cp.tsr
DIGEST=$(jq -r '.trusted_timestamps[0].digest_hex' checkpoint.json)
# Same CA-chain rule as Part 3: obtain the issuing authority's ROOT certificate
# (the token embeds the signing certificate and intermediates).
openssl ts -verify -digest "$DIGEST" -in cp.tsr -CAfile tsa-root.pem

The digest is SHA-256 of the whole checkpoint body, so the token binds the size and the root together — a token over a bare root would be silent about how much log it covered. Checkpoints are anchored to two independent authorities; either one establishes the time on its own.

Prove YOUR record reaches the anchored head

When the log head has been committed to an external append-only log (Sigstore Rekor), coverage of your record is checkable: fetch the anchor, then an inclusion proof at the anchored size, and fold it yourself with the exact recipe from Step 2.

curl -s https://acreseal.com/api/transparency/anchors > anchors.json
HEAD_POS=$(jq -r '.latestAnchor.head_position' anchors.json)
HEAD_DIGEST=$(jq -r '.latestAnchor.head_digest' anchors.json)
SEAL_ROOT=$(jq -r '.seal.merkle_root_hash' seal.json)
curl -s "https://acreseal.com/api/transparency/proof?leaf=$SEAL_ROOT&tree_size=$HEAD_POS" > logproof.json
# Fold: leaf = SHA256(0x00 || seal_root_bytes), each sibling as
# SHA256(0x01 || left || right) per the proof's position tags,
# then compare your result to $HEAD_DIGEST — the anchored head.

If latestAnchor is null, no anchor exists yet and every sealed record is pending_anchor. If the proof answers included_at_size: false with beyond_tree_size, your record entered the log after the anchored head — a timing state, not a problem. A fold that does not reach the anchored head is worth reporting: the verify bundle treats that as an integrity alarm and refuses to issue.

Look the anchor up on the provider, publicly

The anchor row's provider_reference is the Rekor log index, and its provider_receipt is the provider's response verbatim — but you need neither on trust: look the entry up on the public instance yourself.

REF=$(jq -r '.latestAnchor.provider_reference' anchors.json)
curl -s "https://rekor.sigstore.dev/api/v1/log/entries?logIndex=$REF" > rekor.json

# Rebuild what was committed: the checkpoint BODY (published verbatim —
# never re-render it), its SHA-256 digest, then the SHA-512 OF THE HEX
# STRING (Rekor requires SHA-512 imprints for Ed25519 entries):
jq -rj '.body' checkpoint.json > cp-body.txt
CP_DIGEST=$(shasum -a 256 cp-body.txt | cut -d' ' -f1)
printf %s "$CP_DIGEST" | shasum -a 512 | cut -d' ' -f1
# Compare that to the Rekor entry's spec.data.hash.value:
jq -r 'to_entries[0].value.body' rekor.json | base64 -d | jq -r '.spec.data.hash.value'

The committed artifact bytes are the 64-character ASCII hex string of the checkpoint digest — so the provider's data.hash.value is SHA-512 of that string (Rekor's requirement for Ed25519 entries), and the digest itself is SHA-256 of the body, which binds the origin, tree size and root together. The entry's signature is ed25519ph (RFC 8032 pre-hashed) by the same key published at /.well-known/acreseal-seal-key.pem — sigstore tooling verifies it against that key (plain openssl pkeyutl cannot; it speaks only pure Ed25519). The entry's own inclusion proof is Rekor's tree, checkable with Rekor tooling.