How a Purity Analytics COA gets signed — and how the signature is checked.
The chain of trust from raw analytical data to a signature you can independently verify offline in Adobe Acrobat Reader. No magic, no proprietary protocols — just standard public-key cryptography and the same trust roots Adobe ships in every install.
From completed test to signed PDF — five stages.
Analytical data lands
Lab results are entered into the Purity Analytics platform, reviewed for completeness, and locked into an immutable test_result_revision record in PostgreSQL. The data itself is what gets signed — not a screenshot, not a CSV, but the canonical structured record every downstream surface reads from.
Unsigned PDF is rendered
A deterministic PDF renderer composes the COA from the locked revision: cover page with the product, batch, vial photo, and brand; analytical results table; methods detail; disclaimer. The SHA-256 of the rendered bytes is recorded in the unsigned_coa_pdf table as the integrity baseline.
USB-token signing on a hardened workstation
A dedicated signing worker pulls the unsigned PDF and submits it to a FIPS-certified USB hardware token holding the private key for the Purity Analytics LLC Sectigo Document Signing certificate. The token requires a PIN, never exports the private key, and is physically present in our office. The worker runs pyHanko to embed a PKCS#7 detached signature in the PDF using RSA-SHA512.
RFC 3161 trusted timestamp
At sign time, the worker also requests a trusted timestamp token from timestamp.sectigo.com (RFC 3161). The TSA's signed token is embedded inside the PDF's PKCS#7 envelope as an unsigned attribute, fixing the exact UTC moment the signature was applied. Without a TSA token, expired certificates couldn't be trusted retrospectively; with it, Adobe can verify the cert was valid at signing time.
Signed PDF lands in immutable storage
The signed PDF is uploaded to Azure Blob Storage at a fingerprinted path (pa-coa-signed/<org>/<result>/<sha>.pdf), and a row is written to signed_coa_pdf with the new SHA-256, the TSA-derived signing time, the cert subject/issuer/serial/validity, the signature algorithm, the TSA URL, and the raw TSA token (base64) for offline re-verification. The verify website immediately starts serving the signed bytes for that artifact.
Why Adobe Reader believes the signature.
A digital signature on a PDF is only as good as the trust chain behind the certificate that produced it. For Purity Analytics COAs, the chain has three links — and one of them ships inside every Adobe Reader install.
- Subject CN
- Purity Analytics LLC
- Issuer CN
- Sectigo RSA Document Signing CA
- Serial
- 80EE9C34821454C706346FA64888B1B5
- Valid
- 2026-05-18 → 2027-05-18
- Use
- Document signing (PKCS#7 over PDF ByteRange)
Sectigo's purpose-built intermediate for document signing. Cross-signed by Sectigo's public roots and recognised by Adobe's AATL programme.
Adobe Acrobat Reader ships with a bundle of root certificates vetted by Adobe through their AATL programme. Sectigo's document-signing roots are on that list. This is why Adobe shows a blue "valid" banner the moment the PDF opens — no internet round-trip required for the trust decision (only for revocation checks).
What runs on every page load.
The verify website doesn't cache "this COA is valid." Every request to verify.purityanalytics.com/coa/<id> fires the same five-step verification ladder. The Verified at timestamp on the technical-evidence panel is the receipt — it changes every refresh.
Hash binding
Download the linked PDF bytes from Azure, recompute SHA-256, compare to the value persisted on signed_coa_pdf. Mismatch ⇒ document_modified. Storage outage ⇒ revocation_check_unavailable (never "valid").
PKCS#7 verification
Parse the embedded SignerInfo, validate the cryptographic signature over the PDF ByteRange, re-check the certificate chain to AATL, validate the RFC 3161 TSA token. This is the same algorithm Adobe runs in step 1 of opening the file.
Revocation freshness
Periodic background task checks OCSP for the leaf and TSA certificates and caches a per-artifact revalidation result. If a cert has been revoked since signing, the verify page displays cert_revoked.
Administrative revocation
Independent of cryptography: if a COA is administratively revoked in the database (for example because downstream data requires correction), the verify page surfaces signature_revoked instead of valid — even though the PKCS#7 signature is still mathematically intact.
Verified-at timestamp
The API writes the server wall-clock at response time into the response payload. The verify page renders it on the Technical evidence panel. Refresh the page and the value changes — the visual cue that the hash check actually ran this request.
You don't have to trust us — verify everything offline.
Because the signing evidence is stored verbatim in the PDF itself, you can verify a Purity Analytics COA without touching our infrastructure at all.
1. Download the PDF
From the verify website (View / Download COA PDF button) or directly from the QR code.
2. Disconnect from the internet
Adobe Acrobat Reader needs the internet only for OCSP / revocation checks. The signature math itself is offline.
3. Open in Adobe Reader
Even offline, you'll see the blue trust banner — because the AATL root bundle is local and the entire trust chain is embedded in the PDF.
4. Inspect Signature Properties
Right-click the signature → Show Signature Properties. Compare every field — signer, issuer, serial, validity, algorithm, signing time — to what verify.purityanalytics.com shows. They must match because they came from the same PKCS#7 block.
The standards behind every COA signature
- ISO 32000-2 PDF 2.0 document format, defining the digital signature dictionary, ByteRange, and signed-attributes structure.
- RFC 5652 Cryptographic Message Syntax (CMS) — the PKCS#7 envelope format Adobe parses to validate signatures.
- RFC 3161 Time-Stamp Protocol — the format of the trusted-timestamp token Sectigo's TSA produces and that gets embedded in every COA.
- RFC 5280 X.509 PKI — the certificate chain validation rules Adobe applies to the Purity Analytics → Sectigo intermediate → AATL root path.
- RFC 6960 OCSP — the protocol Adobe and our Tier-3 revalidator use to check whether the signing certificate has been revoked since issuance.
- AATL Adobe Approved Trust List — the program defining which document-signing CAs Adobe Reader trusts out of the box. Sectigo Document Signing is on the list.
Educational use, no reliance, and liability limits.
These pages are general analytical education only. They are not medical, safety, legal, regulatory, quality-system, purchasing, or product-use advice, and they do not state that any material is safe, effective, sterile, injectable, therapeutic, approved, compliant, or fit for human or animal use.
- Official standards, signed lab records, applicable law, and qualified professional review control.
- Visitors use and rely on this content at their own risk.
- To the fullest extent permitted by law, Purity Analytics LLC disclaims warranties and liability for losses arising from access, use, or reliance.