What a forensic web page acquisition produces: a real example, file by file.

The times below come from the logs/acquisition-log.txt log, in Italian time (CEST). Before starting, the computer clock was compared with three NTP servers (time.google.com, pool.ntp.org, time.cloudflare.com), all of which responded: a consensus offset of 10 ms; the software reports a maximum deviation from the consensus of 22 ms.

evidence/ — the main evidence

• ReplayWebPage.wacz (1.69 MB) — the session's web archive. Inside is a WARC file (ISO 28500) with the capture's records, including the resources recovered afterwards and the declared local snapshot (index.certo-snapshot-20261012160116.html): traffic observed during the session must be told apart from derived resources. A compatible reader such as replayweb.page can replay the archived material, subject to capture and replay limitations. Next to it, disclaimer_wacz.txt explains what to expect: an ordinary site usually replays; a web application like X or Instagram may not.
• video/ — the WebM video of the browser window (the one above) and video-log.json, with the recording start, save and stop times.
• interactions/user-interactions.json — 57 recorded events: 53 relating to mouse movements, scrolling (with the position) and DOM mutations, plus four tracking activation events. They are not all manual operator actions: some scrolling happens during the automatic full-page capture.
• javascript-state/ — three snapshots of the page's global variables (203 each) and of sessionStorage.
• tracing/performance-metrics.json — 14 snapshots of browser metrics during the session; source-artifacts/favicon.ico — the site icon.

pages/ — the visited page

One subfolder for each logical page visited; here just one, 001_certo.acquisizioniforensi.com_721abda8/. Inside:

• screenshot-viewport.jpeg and page.html (60,127 bytes) — the visible area and the HTML taken live at 18:00:06: they are the reference for the page state at the time of the visit.
• screenshots/ — the session's 7 screenshots, one automatic and six taken by the operator, with the time to the millisecond in the name.
• screenshots-fullpage-live/ and screenshots-fullpage/ — the full page twice, in 11 sections each: the first live at the end of browsing, the second captured again afterwards. The reason is stated in page-metadata.json: both are kept so they can be compared, and the second carries its delay (fullpageDriftMs: 65,497 ms, measured from the start of the acquisition to the start of the recapture).
• html-snapshots/ — 12 dated HTML copies, each with its metadata file: they document the DOM state at their save times; they are not a continuous record of every change.

network/ — the network

• network.har (104.10 KB) — the HTTP traffic in HAR format: 17 requests, all answered with 2xx, with headers, timings and the IP of the server that answered (89.116.109.91). Other JSON files — requests.json, responses.json, resources.json, statistics.json and the maps url-mapping.json and resources-mapping.json — provide views and summaries of the network collection: their counts do not necessarily match the HAR entries (statistics.json, for example, reports 18 requests and 19 responses).
• http-headers.txt — the main page's headers. Here they reveal a content delivery network (CDN): server: hcdn, x-hcdn-cache-status: DYNAMIC. The report draws the right conclusion: the contacted IP is a CDN node, not the origin server, which cannot be seen from there.
• dns-lookup.txt, whois.txt, traceroute.txt — the name's DNS records (two IPv4, two IPv6), the domain registration data (registered on 7 July 2017, registrar Hostinger) and a traceroute: 19 hop positions, three without a response, towards 89.116.109.153, the address resolved at the time of the check, which differs from 89.116.109.91, contacted by the browser during the visit. The DNS does not contain the contacted IP either: the report flags it and explains why (rotating addresses, measurements taken at different moments).
• cookies.json, cookies-detailed.json, cookies.txt — the 4 cookies set by the site. The forensic browser starts with no cookies, cache or extensions: the ones you find were set by the site during the acquisition.
• completeness-report.json — the check lists 19 detected HTTP(S) resources: 10 already collected and 9 recovered through subsequent requests, declared derived evidence because they were obtained after the capture and may differ; one inline resource is counted separately. The 100% figure refers to this list, including the derived recoveries, not to the entire website or every possible dynamic resource.

tls/ — the site certificate

ssl.txt and ssl-data.json summarise the certificate the server presented (just one, for the whole session). certificates/ holds the full chain — site certificate, intermediates, root — as .crt and .pem. The certificates document the covered domain name, issuing authority, validity period and certificate chain. This is a domain-validated (DV) certificate issued by Let's Encrypt: it attests control of the domain; it does not identify the site's legal owner or guarantee its content. To read one: openssl x509 -in <certificate.crt> -text -noout, which shows the certificate but does not by itself validate the chain.

resources/ — the page resources

site-structure/ holds the files that make up the page, saved with the site structure: the HTML (index.html, the DOM copy dom-snapshot.html, the it/ version), the stylesheet, fonts, scripts, logo and icons, plus an image embedded in the HTML (data-urls/). The files have accompanying .meta.json records (source address, type, date, size…): the available fields vary according to the collection method. File hashes are in the bundle's inventories.

reports/, hashes/, logs/, metadata/

• reports/report.pdf (24 pages) and report.txt — the acquisition report: data, timings, NTP, network and CDN, four hashes (MD5, SHA-1, SHA-256, SHA-512) for the main artifacts, operator, declared scope, certificates, tool attestation with the program's hash, explicit statements on the method. report.tsq and report.tsr are the request and response of the Sectigo timestamp on report.txt.
• The text lists: links.txt (links on the page), screenshots.txt (29 screenshots: 7 from the session and 22 of the full page), downloads.txt, objects.txt, interactions.txt, cookies.txt, system-info.txt and system-processes.txt (the computer the program ran on).
• hashes/file-hashes.json — the general inventory, with SHA-256 and size of 147 files (40.17 MB, 42,120,525 bytes). Its SHA-256 hash is written inside report.txt before the timestamp, so the timestamp on the report also covers the inventory. Left out, and the report lists them with the reason: the report itself and its timestamp, the inventory (it cannot contain its own hash), the dashboard and a technical file of the upload.
• logs/acquisition-log.txt — 246 events, no errors or warnings; acquisition-log.at-report.txt is its copy at report time. metadata/ — operator, declared scope (scope-summary.json), acquisition data.

Whoever receives the bundle — a judge or a party-appointed expert — need not open 167 files one by one. data/interactive.html presents them in sections: summary, visited pages, screenshots, video, chain of custody, completeness, hash inventory, acquisition flow, network, certificates, cookies, interactions, log, file map, standards and integrity check. The dashboard is a derived view, not primary evidence. It is excluded from the file-hashes.json inventory anchored by the report timestamp, but included in the BagIt manifest and therefore indirectly covered by the InfoCert seal: modifying it would make the BagIt integrity check fail, without touching the other files. It is viewed locally; the public register lookup, however, uses the Internet and sends the evidence hash, while recomputing hashes does not upload the files to the server.

1. Download the bundle from /zip/W2zAEe and check its hash: shasum -a 256 on macOS, sha256sum on Linux, certutil -hashfile … SHA256 on Windows. The result must be a361f4f7da9aa6a858b40c7e78c2b25d4f3692c127d35083e85840e5dff91498, the same hash as in the email and the report.
2. Extract the ZIP. On Windows use 7-Zip: the built-in extractor fails on long paths, and this bundle has some (the README.txt says so too).
3. From the bundle folder run sh verify.sh on macOS or verify.bat on Windows. With sh in front: the script in the ZIP is not marked executable.
4. Read the individual check results, not just the last line: SKIP means "not performed". The final BUNDLE VALID message also appears when the signature or timestamps were skipped for lack of tools: a verification is complete only if those checks are reported as OK.

This is the result we got on macOS, with the verification kit already present, on the copy downloaded from the server. The output is abbreviated and annotated: the 165 per-file "OK" lines are summarised in two comment lines.

What you need

• File hashes: nothing to install, they are recomputed with what is already on the computer.
• Timestamps: OpenSSL 3. On macOS the system ships LibreSSL, which the script does not use; Windows has no OpenSSL. You can put openssl.exe, with its libraries, in a tools folder next to the script.
• Ed25519 signature: besides OpenSSL it needs the certo-bagit tool with the signature verification script. OpenSSL alone does not check it.
• The verification kit: if the tools are missing, verify.sh on macOS and verify.bat on Windows try to download a kit from acquisizioniforensi.it and check its hash, which is written in the script. We have not tested Linux: with OpenSSL 3 on the system the script checks the timestamps, but the automatic kit is designed for macOS.
• The network: CERTO_NO_NETWORK=1 disables both the kit download and the online register query. On macOS: CERTO_NO_NETWORK=1 sh verify.sh; in the Windows command prompt: set CERTO_NO_NETWORK=1, then verify.bat.

The three timestamps, by hand

verify.sh checks the inner anchor and the external seal; it does not check the timestamp on the report. All three are verified with OpenSSL 3 and the bundle's tsa-ca.pem file. On macOS use the full path of OpenSSL 3 (for example /opt/homebrew/opt/openssl@3/bin/openssl), because the system openssl command is LibreSSL:

We ran all three commands: each one answers Verification: OK. This confirms the pairing between data and timestamps with the certificates supplied in the bundle; the qualified status of the InfoCert service is checked separately, on the EU Trusted List.