Verify a certificate offline

Raw cryptography and platform trust answer different questions. Ordinary verdicts and the unsigned demo are not certificates. The public reference verifier computes both checks and names them separately. raw_signature_valid: does this exact document match this signature under this public key? The key displayed on the same website is evidence, not an independent trust root.

platform_valid additionally means that the key is a retained certificate-purpose key in an externally pinned signed keyring, the complete revocation-head history reaches the required checkpoint, and no matching revocation exists. A full offline verifier therefore needs that independently provisioned root pin and signed history as well as the certificate. If any trust evidence is missing, stale or incomplete, platform verification must fail closed. These two names describe the checks; the hosted API reports the platform result as valid and status.

1 — Save the candidate public key for the raw check

2 — Split the document

The delivered envelope contains the inner certificate object and the signature_b64 value. Save the object as valid JSON in certificate.json and the base64 string in signature.txt. Transport whitespace and object-key order are not signed; the verifier first applies json-sort-keys-ascii-nospace-nfc-float12.

3 — Full offline platform verification

$ pip install alphaassay-verify
$ python -m alphaassay_verify verify     certificate.json signature.txt trust_bundle.json     --root-pin 64-lowercase-hex-root-fingerprint
{
  "valid": true,
  "signature_valid": true,
  "chain_valid": true,
  "status": "valid"
}

The root fingerprint must come from an independent release channel, not from the bundle it authenticates. The local signed bundle must contain the complete revocation-head history and satisfy your minimum trusted checkpoint. If you do not possess those artifacts, fail closed or use the hosted platform verifier; do not substitute the public key printed by this page.

4 — Raw signature evidence only

$ python -m alphaassay_verify signature-only     certificate.json signature.txt alphaassay.pub
{
  "valid": true,
  "reason_code": "valid"
}

Here valid:true means only raw_signature_valid=true. The public verifier uses canonical_bytes internally; raw OpenSSL or Node crypto over the downloaded JSON file is not equivalent unless it reproduces the named canonicalization and passes the published golden vectors.

Library integration

from alphaassay_verify import verify_trusted_certificate

result = verify_trusted_certificate(
    certificate, signature_b64, public_key_pem=None,
    trust_bundle=local_bundle,
    pinned_root_fingerprints=(independent_root_pin,),
    minimum_head_sequence=trusted_checkpoint_sequence,
    minimum_head_hash=trusted_checkpoint_hash,
)
assert result["valid"] is True

A semantic modification — a changed value or key — makes signature verification fail. Passing only the raw mode does not establish who controls the key or whether the certificate was revoked. The hosted /verify page applies the platform trust bundle and returns a valid result only after the keyring, history, checkpoint, purpose and revocation checks all pass.