Daily audit checkpoints
Quick answer for InfoSec questionnaires
Each day, an independent third-party Time Stamping Authority signs the day's audit-chain seal. The resulting certificate can be verified offline by anyone, without access to CaseFlow systems or any trust in CaseFlow. This feature is available on the Multi-Practice plan.
What this feature does
Each night, an automated process takes the final cryptographic seal of that day's audit chain and submits it to a public Time Stamping Authority over an encrypted connection. Two independent authorities are used: FreeTSA (primary) and DigiCert (fallback). Each authority applies its private key to produce an RFC 3161 TimeStampResp token, a binary certificate that records what your chain seal looked like at that moment in time. The token is stored in CaseFlow alongside metadata describing which day and which chain it covers. Anyone with the token, the chain seal, and the authority's published public certificate can verify the proof offline using OpenSSL.
Why this matters for an audit
Your firm's records sit in a system you control. Your audit log is sealed by software you operate. An auditor's first question is: "How do I know you didn't alter the records after the fact?" A cryptographic chain inside CaseFlow partially answers that question, but a determined insider with write access could reconstruct the chain after modifying records. The daily checkpoint addresses that limitation. The TSA's private key is held by an organization in a different jurisdiction that has no relationship to your firm or to CaseFlow. Nobody can forge its signature.
Bar disciplinary investigation. A state bar investigator subpoenas your trust accounting records. You produce the export from CaseFlow along with the daily signed checkpoints covering the dates in question. The investigator's office downloads FreeTSA's public certificate from FreeTSA's own servers and runs the verification against each checkpoint. Each one returns a clean result: the audit log was in this exact state on this specific date. Your word and CaseFlow's word are not part of the verification path.
Enterprise client InfoSec questionnaire. An AmLaw-100 client's IT security team sends a SIG questionnaire during vendor onboarding. One question asks about audit-trail tamper-evidence controls. You describe the RFC 3161 daily checkpoint mechanism, link this page, and attach a sample .tsr token from a recent day. The question is closed on the first review cycle because the verification path is public, standard, and does not require trusting the vendor.
Discovery in litigation. Opposing counsel asserts that records were altered before production. You produce the audit-log export alongside the daily checkpoint tokens covering the relevant period. Their forensic expert recomputes the day's chain seal from your export and runs it against the TSA-signed token. If the recomputed hash matches what the TSA signed, the records existed in that state on that date. If anything was changed after the checkpoint was issued, the verification fails and the discrepancy is visible.
In plain terms: the daily checkpoint is an outside witness. Your firm does not run it. CaseFlow does not run it. An organization in a different jurisdiction signs the day's seal and publishes its public key for anyone to use. Three years from now, anyone with the .tsr token and the chain seal can prove what was logged on that date, without needing access to CaseFlow systems.
Finding and reading the page
The checkpoint viewer is at Utilities in the sidebar, then Audit checkpoints. It is available to firm administrators on the Multi-Practice plan only. On Solo and Growth plans, a lock badge appears on the sidebar entry. If your plan does not include this feature, contact support to discuss an upgrade.
The listing shows one row per calendar day, newest first. Each row displays the date, the chain it covers (Activity log or Trust audit), a status pill, the number of audit entries covered that day, the first 12 characters of the chain seal (hover for the full value), and the TSA that responded. Two filters narrow the listing: a chain-kind dropdown and a date range with a from-date and to-date input. The actions column on each row shows a .tsr download button on signed rows and a .json manifest button on all rows.
| Status | What it means | What you do |
|---|---|---|
| Signed | The TSA returned a valid signature for that day's chain seal | Download the .tsr token when an auditor or forensic expert requests proof |
| TSA unavailable | Both FreeTSA and DigiCert were briefly unreachable when the nightly process ran | The following night's run retries automatically; no action needed |
| Empty chain | No audit events were recorded on that calendar day | A sentinel row is still written so the absence itself is on record; there is nothing to verify |
| Error | A different problem occurred; the row shows the cause inline | Contact CaseFlow support if the status persists beyond one day |
What the two downloads contain
Manifest (.json) | Signed proof (.tsr) | |
|---|---|---|
| What it is | A plain-text label file listing what the signed proof covers | A binary cryptographic certificate from an independent Time Stamping Authority |
| Who reads it | You, your auditor, or anyone reviewing the records | Cryptographic verification software, typically openssl ts -verify |
| What it proves on its own | Nothing on its own; it labels and describes the proof file | Nothing on its own; it needs the chain seal to verify against |
| What you do with it | Open it to confirm which day and which chain seal it covers | Hand it to your IT person, outside counsel, or forensic expert along with the manifest |
The 2 files work as a pair. The manifest tells the verifier exactly which chain seal to expect and records the TSA URL, the entry count, and the date. The .tsr is what mathematically certifies that the seal was presented to the TSA at the recorded time. Without the manifest, the .tsr is an anonymous blob. Without the .tsr, the manifest is an unverified label.
For your auditor or forensic expert
Forward this section to your IT person or outside counsel.
Verification command and authority public keys
To verify a daily checkpoint, you need 3 things: the chain seal from the manifest's chain_root_hash field (a 64-character hex string), the .tsr token file downloaded from the checkpoint viewer, and the TSA's public CA certificate.
Convert the chain root hash from hex to raw bytes, then run:
# Verify the TSA signature against the chain root hash
openssl ts -verify -data <chain_root_hash_bytes> -in <downloaded.tsr> -CAfile <tsa-ca>FreeTSA's public CA certificate is available at https://freetsa.org/files/cacert.pem and https://freetsa.org/files/tsa.crt.
DigiCert's TSA root certificate is published at https://www.digicert.com/kb/digicert-root-certificates.htm (look for "DigiCert Trusted Root G4").
If the command returns Verification: OK, the chain seal you supplied was signed by the named TSA at the time recorded inside the .tsr token, and the signature has not been altered since.