Trust Center
The Trust Center is the place in the console where the platform's cryptographic material is shown, not asserted. Every value is read live from the running system each time you open it, fingerprints are recomputed on the server, and it exposes public material only - key identifiers, fingerprints, thresholds and expiry. No private key is ever shown, here or over the API.
You will find it in the console under Trust. It requires the evidence-read permission.
Update trust
The first panel lays out the update-signing roles and their custody. The label depends on the trust model selected for the tenant:
- With Meshanics-managed trust, every role has a tenant-specific, non-exportable Google Cloud KMS key. Root and targets are lifecycle roles. They are used only when the tenant trust is created or rotated. Publisher, snapshot and timestamp are online roles used to publish and refresh metadata.
- With customer-controlled trust, root and targets stay in the customer's external signer or offline custody. Publisher, snapshot and timestamp remain online roles.
For each role you see its key identifiers, key type, signature threshold, current version and expiry. During a managed rotation, the panel also shows the pending root, when it was prepared, how many active devices have accepted it, and any error that needs attention. Platform owners can inspect the lifecycle job and request an urgent rotation without bypassing device verification.
See Trust lifecycle for renewal and notification behavior.
Device identity
The second panel shows the certificate authority that signs device identities, as a chain of certificates. Each node shows its subject, issuer, serial number, SHA-256 fingerprint, validity window, key algorithm, and whether it is a certificate authority - with the computed expiry status so an approaching renewal is visible, not a surprise.
Audit & evidence
The third panel surfaces the append-only, hash-chained audit log as a first-class, verifiable object: live chain-integrity status (recomputed on every load - a chain that can complain is one you can believe), the chain head, the event count, a window of recent actions, and a one-click download of the signed audit export for third-party verification against the published key.
Artifact provenance
The fourth panel answers "what exactly are we shipping, and how is it vouched for?" Every artifact is signed into a TUF target; the panel shows that, whether the artifact carries a software bill of materials, and its open-vulnerability posture by severity. An artifact that is signed, carries an SBOM, and has no open critical findings is shown as signed and vetted - the admission posture made visible.