Verify a release
How to check that the Cenovel files you install are the ones Cenovel published: the OVA’s checksum, the signature on release bundles and site collectors, and the installed release.
Updated October 4, 2026
What you receive
- The OVA
- For a new install. It comes with its SHA-256 checksum, published by Cenovel next to the download.
- Release bundles
- Files ending in
.cenovel, for installs and upgrades. Each is signed with Cenovel’s release key, and the appliance checks the signature itself. - Site collectors
- Signed with the same release key, and checked again by the console and by the collector before it starts.
- The release public key
- The
release.pemfile the appliance trusts. Take it from Cenovel’s download area, never from an email attachment.
Check the OVA
Compute the file’s SHA-256 and compare it, character for character, with the value Cenovel publishes. If they differ, don’t deploy it; download it again and tell us.
Windows (PowerShell)
Get-FileHash .\cenovel-1.1.0.ova -Algorithm SHA256macOS
shasum -a 256 cenovel-1.1.0.ovaLinux
sha256sum cenovel-1.1.0.ovaThe OVA is not signed with a certificate, so vSphere shows no publisher for it. The checksum is how you check it.
Check a release bundle
On the appliance, as root:
cenovelctl release verify cenovel-1.1.0.cenovelThis checks the bundle’s signed manifest against the trusted keys in /etc/cenovel/trust (Ed25519 signatures) and the SHA-256 digest of everything in it. The installer and the updater run the same check before anything is staged, and refuse a bundle that fails, saying why: for example “Release manifest signature is invalid.” or “Release payload digest is invalid.”
Check what is installed
To confirm the files running on the appliance are still the signed release:
cenovelctl release verify-currentA failure here means the installed files are not the signed release. Treat it as a possible incident; see Incident and breach response.
Site collectors
A site collector runs only a release signed by the Cenovel release key, and the console checks the same signature before it registers a collector. Before a new collector release reaches your sites, an Administrator EX approves it by pasting its signed manifest. A collector that refuses to start says why: the code was changed, the key differs, or the signed file is missing.
See also: Security & data: signed site collectors · Upgrades & rollback · Security advisories