Preservation certificates

A preservation certificate attests, signed and dated, the state of an .obf archive or of a file at a given moment: its fingerprints, where it is, its copies, its latest check. You hand it to a third party (a client, an insurer, an institution) who can verify it without you, offline or on a web page.

The Certificates screen (group Attest) keeps the register of issued certificates, issues them, revokes them and verifies a PDF. Issuing a certificate requires a licence; verifying a certificate is free.

What a certificate attests

For an archive (a specific revision of an .obf archive):

• the project, the archive’s identifier, its revision, its archiving date, its compression engine;
• the SHA-256 fingerprint of the package (the archive’s content file);
• the number of files and the SHA-256 fingerprint of the file list; the list itself (path, size and fingerprint of each file) is the annex, a file delivered with the PDF and copied into its last pages (see “The document”);
• its latest verification;
• its known locations: the medium’s name (its label in Storage Media, otherwise the disk’s name) and the name of the package folder, for example Fonds-Brown-r1 — Disque N2 · N2. No full path is signed or printed: neither your account name nor how your disks are organised;
• its offsite copies sent or verified by Vault: the destination’s name and the date. The bucket, key, host or share stay in your library. A copy whose latest verification failed is not listed.

For an incremental revision (one that holds only what changed since the previous revision), the certificate attests the complete state of the project at that revision, not just the changed files: the number of files, the fingerprint of the list and the annex are those of its inventory, the signed list of every file of the project, unchanged ones included. The package fingerprint remains the revision’s own. The document has the same form as a full revision’s certificate and is verified the same way, in Vault and on the web page. The chain of revisions its restore depends on is not printed: Vault keeps it in its register (the number and manifest fingerprint of each revision verified at issuance).

For a file:

• the project, the file’s path within its project, its size, its SHA-256 fingerprint;
• its latest fixity check;
• the archives that contain it (identifier and revision).

An absence is written and signed, never left blank: “no check recorded”, “no verification recorded”, “no offsite copy recorded”, “no location recorded”.

The certificate also carries its number (for example OV-CERT-2026-00001), its version, its issue date, the name of the issuer, the address where the issuer publishes its key, the signature and any timestamp.

The certificate attests what your library knows about the object at the time of issue. It says nothing about what the object depicts or who created it.

The document

The certificate is a PDF/A-2b, the PDF format intended for archiving. It embeds its signed manifest: the attested values, as data, signed with an Ed25519 signature. Any change to the content or to the page is detected at verification.

The page prints the verification address in plain text and as a QR code (by default vault.obscuraflow.app/c/<number>/<version>), as well as an obscura-vault:cert/… link for the app. If the QR code cannot be produced, no certificate is issued.

The obscura-vault:cert/<number>/<version> link, opened from Preview or a browser, opens Obscura Vault on the Certificates screen:

• if the certificate is in your library’s register, Vault shows its status (valid, superseded, revoked with date and reason), its object and its date, and offers Verify This PDF;
• otherwise (a certificate from another installation, or a link that names nothing), Vault says so and offers Verify a PDF…: the link carries neither the manifest nor the key, only the PDF can be verified.

A malformed link is ignored.

PDFs are saved in the library’s Certificats folder, named <number>-v<version>.pdf. An archive certificate comes with its annex, <number>-v<version>-fichiers.json: the archive’s file list, whose SHA-256 fingerprint is signed and printed on the first page. Hand over both files together. Anyone can check the annex with a plain hashing tool (shasum -a 256 OV-CERT-2026-00001-v1-fichiers.json): the result must be the printed fingerprint. The PDF’s last pages are its readable copy. This way the certificate of an archive of tens of thousands of files stays light and verifies like any other.

Vault never replaces a PDF or an annex already in this folder, and never reuses a number whose PDF is there, even after restoring a database backup older than those certificates. In that case, the Certificates screen points out the PDFs in the folder that are missing from the register.

The certificate page is always written in French, whatever the Mac’s language: it is a signed document meant to last, whose printed text is compared with the signed values. The values themselves (fingerprints, identifiers, ISO 8601 dates) read the same in every language.

Prepare issuance (once)

As long as everything is not ready, the screen shows Issuing is blocked with the list of what is missing, and Open Certificate Settings. Click Settings…:

1. Signing Key: click Create Signing Key. It is stored in the Mac’s keychain. Its fingerprint is shown.
2. Key backup: enter a phrase de passe (passphrase, at least 12 characters), confirm it, then Export a Backup…. Vault writes a file encrypted with this passphrase (by default obscura-vault-cle-certificats.txt). Issuance stays blocked until this backup has been exported: losing this Mac without it would prevent issuing new certificates under this identity (certificates already issued stay verifiable thanks to the public key you publish). On another Mac, Import a Key Backup… reinstalls this key (see Keys and security). Store the file and the passphrase separately; together, they allow issuing in your name.
3. Issuer:
   • Issuer name: printed and signed, it is who attests;
   • Public key address (https): the address where you publish your key file, by convention https://your-domain/.well-known/obscura-certificate-key.json. It is mandatory: it goes into the signed manifest and cannot be added afterwards;
   • Number prefix: OV by default, which gives OV-CERT-2026-00001.
4. Verification and Timestamping:
   • Verification address: leave empty for Obscura Vault’s permanent address, https://vault.obscuraflow.app/c. Only change it for a mirror you host;
   • RFC 3161 timestamp authority: optional. Empty, no timestamp and no network call; the certificate prints that its date is declarative. Filled in (https), each issuance asks this authority for a token attesting that the signature existed at its date. If the authority does not respond, issuance fails rather than producing a weaker certificate.
5. Click Save.

Publish your public key

Click Export Public Key File…: Vault writes obscura-certificate-key.json, which holds the public keys of your certificates. Publish this file at the address given in Public key address, on a site you control. That is where the verification page will fetch your key.

Save over the file you already publish (keep a local copy of it): Vault keeps the keys it contains, for example those of an old Mac, and adds its own. A retired key stays in it, so that the certificates it signed stay verifiable online; a key declared compromised leaves it.

For the verification page to be able to read it, the server must allow it to be read from another origin (CORS header). Failing that, the person verifying can paste the file’s content into the page.

Issue a certificate

1. Click Issue….
2. Choose An .obf archive or A file:
   • the archives offered are those Vault created or verified, with their revision, their number of indexed files and their latest verification. An incremental revision carries the mark Incremental and the number of files its certificate will count, that of the complete state of the project. A revision Vault already knows it cannot certify (see below) carries the mark Cannot be certified; once selected, the sheet says why and the Issue button stays inactive;
   • for a file, search for it by its path (Search a file by its path — Search for a file by its path); each file shows its latest fixity check and the number of archives that contain it.
3. Click Issue.

Vault refuses to certify:

• an archive whose latest verification is not “verified” (failed, or archive unverifiable): verify it again or restore it first;
• an archive whose manifest does not carry a signature of your archive keys (changed since archiving, or signed by an unknown key): the fingerprint and the file list are only certified as the archive signed them;
• an incremental revision that is not restorable from the archives folder: a revision of its chain is missing there, or its latest verification there is not “verified”. The message names the revisions in cause; verify them in Archives first;
• an incremental revision from Obscura Flow, which has no inventory: the files deleted since its base are unknown, so the complete state of the project cannot be attested. Make a new full revision of the project and certify that one;
• a file whose latest fixity check does not conform (different fingerprint, file not found or unreadable): check it again first.

An archive that was never verified or a file that was never checked can be certified: the certificate prints it (“no check recorded”; the certificate itself is printed in French) and the sheet warns you. For a stronger certificate, run an audit first.

Vault signs the manifest, requests the timestamp if one is set, produces the PDF, then reads it back and verifies it before saving it: a certificate that does not verify is deleted, never handed out. The number is only consumed at that point. The next number takes into account the register and the PDFs already in the Certificats folder.

Reissue

If the object already has a valid certificate, the button becomes Reissue: “Will replace certificate …: the number is kept, the version is incremented.” Reissue when the object’s state has changed (a new verification, a new offsite copy) or to correct a clerical error. The previous version moves to the Superseded state.

The register

Each issued certificate appears in the register with its number, its status (Valid, Superseded, Revoked), its type (Archive or File), the Timestamped badge if it is, the object, its SHA-256 fingerprint, its date and the short fingerprint of the key that signed it.

A certificate’s context menu (right-click) offers Open PDF, Show in Finder, Verify This PDF and Revoke….

Revoke a certificate

Revoke a certificate that must no longer be trusted. In Revoke…, choose a reason (mandatory):

• Object destroyed, lost or withdrawn: the certified archive or file no longer exists or has left the collection;
• Certificate issued in error: a duplicate, the wrong object, or a non-existent object;
• Forgery found under this number;
• Signing key compromised;
• Withdrawn by the rights holder or by court order.

An optional Optional detail is recorded in the journal. The certificate stays in the register; a revoked certificate still verifies cryptographically, only its status changes. A simple clerical error is corrected by reissuing, not by revoking.

If the signing key itself is compromised, do not revoke certificates one by one: declare the key compromised (below), which revokes them all.

Retire the signing key or declare it compromised

The Key history section of the certificate settings lists every certificate key your library knows: the current key, retired or compromised keys, and how many certificates each signed.

• Remove… (current key): the key signs nothing more and a new key is created, to be backed up before issuing. Certificates already issued stay valid: the old key stays in the public key file.
• Declare Compromised…: do this if the key may have been copied (stolen Mac, backup and passphrase disclosed). The key will never sign again, even reinstalled from its backup; it leaves the public key file and this installation no longer recognises it; every valid certificate it signed is revoked, reason “Signing key compromised”. If it was the current key, a new key is created, to be backed up before issuing.

After either, export the public key file again and publish it: that is how the holders of your certificates, on the web page, stop trusting a compromised key (their certificates signed by it no longer verify online). The revocation status itself is kept by your register: the web page does not know it.

Verify a certificate

In Obscura Vault

Click Verify a PDF…, then Choose a Certificate PDF…. Verification works offline, on a certificate issued by any installation of Obscura Vault.

The result gives:

1. A verdict on the signature:
   • Valid signature, known key: the signed content is intact and the key is one of this installation’s;
   • Intact, but signed by an unknown key: the document has not been modified, but its origin is not verified (this is the case of a certificate issued by another installation, and also of what a forger with their own key would produce);
   • Invalid signature — the content was changed (the content was modified): do not rely on this document;
   • Unreadable certificate;
   • Unsupported manifest version: update Obscura Vault;
   • No certificate in this PDF.
2. The revocation status: Not revoked, Superseded by a later version, Revoked (with date and reason), or Revocation status unknown when this document is not in this installation’s register. Vault recognises a certificate of its register by its signed content and its signature, never by its number alone: every installation numbers from …-00001, and another issuer’s certificate bearing the same number is not yours.
3. Page consistency: Vault compares the printed text with the signed values, the file’s path included (a long path, cut anywhere by the layout, is compared without its line breaks). If signed values are missing from the page: “The printed page contradicts the signed manifest”. The page text is read by a small separate service with no access to your library, your keychain or the network: a booby-trapped PDF cannot reach anything. If that service cannot read the page (damaged or oversized PDF, reading too long), Vault says so (“The page text could not be read”) and still gives the verdict on the signature.
4. The timestamp: absent (declarative date), verified, or a token problem.
5. The annex (archive certificate): Vault looks for the file list next to the PDF (…-fichiers.json) and says whether it is the certified list, whether it was modified, or whether it was not found.

Each verification is recorded in the journal (“Certificate verified”), and in the certificate’s history when it is in your register.

By a third party, on the web

The person who receives your certificate does not need Obscura Vault:

1. They open the address printed on the certificate, or scan its QR code: https://vault.obscuraflow.app/c/<number>/<version>.
2. They drop the PDF onto the page.

The PDF is read by their browser, in memory; it is not sent anywhere. The verification runs in their browser: its only network request is reading your public key file, at the address written in the certificate. Separately, as on every page of the site, Cloudflare’s audience measurement (Cloudflare Web Analytics, no cookie) may load and send Cloudflare the page address, hence the certificate number, and load timings; never the PDF nor the result. It does not run for visitors served by a Cloudflare data center in the European Union.

The page checks the Ed25519 signature over the exact bytes of the signed manifest, the fingerprint of those bytes, that the key is listed in the file you publish, and that the signed number and version are those of the address. It does not check the register status (shown as “unknown outside the register”), does not validate the timestamp (it only says whether one is present), and does not verify your identity: “valid” means “signed by the key this address publishes”. That is why your key’s address must be on a domain people associate with you.