Skip to main content
Every ROOTKey on-premise release is signed. This page is how you check that the release you received is the one we published, and it is deliberately the only page you need to trust before trusting anything else.
ROOTKey never sends secrets by email, chat, or a support ticket. Not registry passwords, not enrolment tokens, not certificates. If you receive something that looks like a ROOTKey secret through one of those channels, it did not come from us — do not use it, and tell us.

​
Verify a release before you install it

Run this before unpacking the archive. It needs sha256sum and cosign, and it changes nothing.
1

Get the public key from your delivery record

Take cosign.pub from the channel that announced the release, not from inside the archive. A key that travels inside the thing it verifies answers the wrong question: if the archive had been tampered with, so had the key.
2

Check the key fingerprint against your contract

The key’s fingerprint is written into your SOW or contract. Two independent channels, so the verification is never circular: a key and a signature that both arrived by the same route prove nothing to each other.
If the fingerprint you compute and the one in your contract disagree, stop and contact us through the channel in your delivery record. Do not resolve the disagreement by trusting whichever one is more convenient.
3

Verify the bundle

The signature first, then the contents. Only the first proves the bundle came from ROOTKey; sha256sum -c on its own proves the archive is internally consistent, which a tampered archive also is.
Both exit non-zero on failure. Run them from the unpacked bundle directory, before running the installer.
4

Compare the archive checksum against what we told you

Compute the archive’s SHA-256 with sha256sum rootkey-onprem-<version>.tar.gz and compare it against the value in the message that announced the release — not against a value that travelled with the file. A checksum shipped alongside the thing it checksums proves only that the two arrived together.

​
What a failed check means

The release was not signed. Every ROOTKey release is, so an unsigned bundle either did not come from us or was built incorrectly. Do not install it. Contact us.
Either the archive was altered after we signed it, or you are checking against the wrong key. Re-download the bundle and re-check the key fingerprint against your contract. If it fails a second time, contact us — do not install it in the meantime.
Files have been added, removed or changed since the bundle was built. The usual innocent cause is unpacking a new release over an old one in the same directory. Unpack into a clean directory and re-check. If it still fails, re-download.
That marker is stamped only on an internal development build, which must never be delivered. Report it to us — it means something went wrong on our side, not yours.
The content check still runs, but the signature check — the one that matters — does not. A checksum file proves the archive is internally consistent; only the signature proves it came from us. Install cosign before installing the platform.

​
Signing keys

A superseded key is retired but never destroyed, so that a bundle you archived years ago can still be verified against the key it was actually signed with.
Ask your ROOTKey contact for the current key fingerprint, and check it against the value in your contract. If you need to verify an older bundle, ask for the key it was signed with by release version. The two-channel rule applies either way: the fingerprint and the signature must never reach you by the same route.
The Control Plane’s licence signing keys are a different set with a different lifecycle, and you do not need them: your deployment fetches the public half from the Control Plane and verifies each licence locally. They are custodied under a two-person ceremony.

​
How things reach you

Everything that crosses the boundary has one named channel. Nothing uses email.
The enrolment token is single-use and expires, 24 hours by default and 7 days at most, enforced when it is issued and again when it is consumed. That is why a one-time link is enough: the link cannot outlive the secret it carries.

​
Registry credentials

Yours are issued per client: scoped to exactly the repositories your Data Plane pulls, pull-only — no push, no delete, no catalogue listing — and with an expiry date. Rotation is a single operation on our side and does not interrupt you, because the previous password keeps working until you confirm the new one. Pulls are recorded in the registry’s audit log against your token’s identity. That record is what lets either of us answer “which release is deployed, and when was it fetched” without asking the other.

​
Reporting a security issue

If you believe you have found a vulnerability in the ROOTKey platform, in a release bundle, or in this verification process, contact us through the channel named in your delivery record and mark it severity 1. We will acknowledge within one business day. Please do not open a public issue for a suspected vulnerability.
→ Next: Requirements · Installation