Certification & Online Trace Collection · service active
WACZ · ISO 28500/ eIDAS timestamping/ Client area
C.E.R.T.O.
Sign in Register free
IT EN
C.E.R.T.O. / Modules / Digital files
02 · FILE

Digital files

Download and seal a file published online, documenting its origin, network path and bit-for-bit integrity.

C.E.R.T.O. Desktop “File Acquisition” screen: paste the URL of the file to download, choose the timestamp (free RFC 3161 or qualified eIDAS InfoCert) and start. Three modes: single file, resource extraction from a page, URL list.

C.E.R.T.O.'s Files module performs the forensic download of remote files: it downloads the exact byte-stream delivered by the server — a PDF, an image, an Office document, audio, video, an archive — and seals it as digital evidence with cryptographic hashes, HTTP headers, TLS certificates and a double RFC 3161 timestamp. It is designed for court-appointed and party experts, lawyers and law enforcement who need to freeze a file published online — a photo, a price list, a contract, a document — with a full chain of custody and verifiable integrity.

Key features

What this module does.

  • Automated multi-step procedure with double verification download.
  • DNS, WHOIS, SSL certificate and traceroute analysis of the origin.
  • Anti-CDN/anti-bot browser fallback (Cloudflare, Akamai…) with documented bypass.
  • Hash comparison between the two downloads to guarantee integrity.
  • BagIt 1.0 bundle signed with Ed25519, double RFC 3161 timestamp and CASE/UCO.
Final forensic report: the interactive dashboard of the file bundle — summary, downloaded file with preview, hash inventory, network, HTTP headers, metadata, timestamp and integrity check.
Forensic pipeline

How the module operates.

A repeatable, documented procedure: from synchronised time to the cryptographic seal, every step on the downloaded file leaves a verifiable trace inside the bundle.

01 · NTP

Synchronised time

Multi-source NTP sync (Google/Cloudflare/pool) with documented offset and roundtrip: the moment of download is anchored.

02 · RESOLVE

Origin & network

DNS resolution of the host, WHOIS query, server IP and capture of the TLS certificate chain: the file's origin is documented.

03 · DOWNLOAD

Exact byte-stream

Download of the file exactly as delivered by the server, without alterations. With CDN/anti-bot in place (Cloudflare, Akamai…) C.E.R.T.O. solves the challenge and discloses it in the report.

04 · HEADERS

HTTP headers

Recording of the request and response HTTP headers (Content-Type, Content-Length, ETag, Last-Modified, server): the transfer context is preserved.

05 · HASH

Fingerprints

Single-pass streaming computation of MD5 + SHA-1 + SHA-256 + SHA-512 (FIPS 180-4): four fingerprints that uniquely identify the file.

06 · METADATA

Metadata

Extraction of embedded metadata: EXIF/XMP/IPTC for images, properties and any signatures for documents, with GPS and creation/modification dates.

07 · REPORT

Report & timestamp

Generation of the forensic report (PDF + TXT) and RFC 3161 timestamp on the report — free cascade Sectigo→DigiCert→GlobalSign, optional qualified eIDAS InfoCert.

08 · SIGN

Signature & double timestamp

manifest.json signed with Ed25519 (RFC 8032) bound to the device + double RFC 3161 timestamp (inner anchor on the manifest, outer seal on the tag-manifest).

09 · SEAL

Sealed bundle

Everything is packaged into a BagIt 1.0 bundle (RFC 8493) with a CASE/UCO description and verify.sh / verify.bat verifiers.

Bundle contents

Everything that gets generated.

Each file acquisition produces a coordinated set of artefacts, each with a precise forensic role, organised into clearly-named folders inside data/.

Downloaded file

The exact byte-stream delivered by the server, kept under its original name — it is the sealed media of the bundle, authoritative and not re-processed.

evidence/<file>

Hash inventory

The MD5/SHA-1/SHA-256/SHA-512 quadruple of cryptographic hashes for the file and every artefact: the basis for an integrity check repeatable by anyone.

hashes/file-hashes.json

HTTP headers

The request and response HTTP headers of the transfer: Content-Type, Content-Length, ETag, Last-Modified, server and cache — the technical context of the download.

network/http-headers.txt

SSL/TLS certificates

The full X.509 chain (leaf + intermediates + root, in PEM and human-readable) of the host the file was downloaded from, with certificate details.

tls/certificates/

File metadata

The embedded metadata extracted from the file: EXIF/XMP/IPTC for images (camera, GPS, dates), properties and any digital signatures for documents.

reports/metadata-report.txt

DNS · WHOIS · Traceroute

DNS resolution, WHOIS registry query (domain owner and registration data) and a map of the network hops from client to host.

network/dns-lookup.txt · whois.txt · traceroute.txt

Forensic report

The report in PDF and TXT (operator, URL, IP, NTP, SSL, size, hashes, forensic statements) with its own RFC 3161 timestamp (report.tsr).

reports/report.pdf · report.txt · report.tsr

System info & log

A snapshot of the operating environment at acquisition time and the chronological log of every step of the procedure, for full traceability.

reports/system-information.txt · logs/acquisition-log.txt

Self-validation

A bundle that proves itself.

The bundle does not need C.E.R.T.O. to be validated: anyone, even years from now, can verify its authenticity with standard tools. The BagIt 1.0 structure and the interactive dashboard make it self-explanatory.

  • interactive.html — the navigable offline dashboard of the bundle: summary, downloaded file with preview, hash inventory, network, HTTP headers, metadata and client-side integrity check.
  • manifest.json signed with Ed25519 (RFC 8032), bound to the identity of the device registered at first launch.
  • Double RFC 3161 timestamp: inner anchor on data/tsa.tsr and outer seal on tagmanifest-sha256.txt.tsr. Free cascade Sectigo→DigiCert→GlobalSign; optional qualified eIDAS InfoCert.
  • manifest-sha256.txt and tagmanifest-sha256.txt (RFC 8493): fixity of the payload and of the control files; no file can be added or altered without the check failing.
  • metadata/evidence.case.jsonldCASE 1.3 / UCO 1.4 description of the evidence, and tsa-ca.pem for verifying the timestamp even offline.
  • verify.sh / verify.bat — standalone verifiers: they recompute the hashes, check the double timestamp and the signature, and declare “VALID BUNDLE”.
FAQ

Frequently asked questions

Forensic file download, evidence validity, supported file types and bundle verification: the most common questions.

What is forensic file acquisition?
It is the download of a file from a remote source (a URL) performed forensically: the exact byte-stream delivered by the server is captured, its cryptographic hashes are computed and it is sealed into a verifiable bundle, so it can be used as digital evidence.
How is it different from a normal download?
A normal download leaves no verifiable trace of origin, time and integrity. C.E.R.T.O. records the URL, the server IP, the HTTP headers, the TLS certificates, the NTP-synchronised time, computes four hashes and applies a double RFC 3161 timestamp with an Ed25519 signature: the file becomes admissible evidence.
What file types can be acquired?
Any file reachable via URL: PDF and Office documents, images, audio and video, archives. For images and documents the metadata (EXIF/XMP/IPTC, document properties, signatures) is also extracted.
Can multiple files be acquired at once?
Yes. Besides a single URL, you can paste a list of URLs for multiple acquisitions, or analyse a web page to find and select images, documents and archives to download and certify.
Is the acquisition valid as evidence in court?
The bundle follows recognised standards (ISO/IEC 27037, BagIt RFC 8493, RFC 3161, CASE/UCO) with an Ed25519 signature and a double timestamp; authenticity and integrity can be verified by anyone, even offline. Evidentiary suitability is therefore technically solid; the final assessment rests with the adjudicating authority.
How is the integrity of the downloaded file verified?
The bundle contains the hash inventory (MD5/SHA-1/SHA-256/SHA-512), the Ed25519-signed manifest, the double RFC 3161 timestamp and the verify.sh / verify.bat checkers: they recompute the hashes and confirm the file has not been altered, with no need for C.E.R.T.O.

Collect evidence with the Digital files module.

Register for free and download C.E.R.T.O. Desktop for Windows and macOS from your client area.