Cryptography & Trust Settings

What this screen is for

Cryptography & Trust is one of the eight purpose groups of Platform Settings, and it holds the roots of trust the rest of the platform stands on: the backend that wraps your key material, the RFC 3161 time-stamping authority signatures are stamped by, the keys that sign user access tokens, and the trust rules applied to key material imported from elsewhere. Opening the group card lists its subsystems as cards; each card drills into its own screen.

Six cards are offered on your install — HSM / Cloud KMS, Timestamping (TSA), Token signing keys, Projection signing keys, Projection signing and Migration & Trust — in that order. Token signing keys and Projection signing keys each appear only if you may read those keys, which every built-in platform role may. A seventh, Managed key backends by Edition, is not offered on a customer-operated install: its card, its sidebar node, its address and its command-palette entry are all withheld there.

Migration & Trust has no screen of its own and is covered here: it is the one card in this group that is a plain list of configuration values rather than a subsystem with records of its own.

What must exist first

Platform Settings is a platform screen, reached in the platform context and served only to the platform tenant. Before you work here:

The permission to read platform configuration, which is what shows the Platform Settings sidebar entry at all. The built-in platform administrator, auditor and viewer roles hold it.
The permission to write platform configuration, for any change. Only the built-in platform administrator holds it; a viewer or auditor sees every value and no edit control.
A third permission for the values marked dangerous. Two of the five Migration & Trust values are among them, and writing one requires the write permission and the dangerous permission together. Only the built-in platform administrator holds both.
Separate permissions again for the two subsystem screens — the key-protection backend and the time-stamping authority each have their own, described on their own pages. Holding platform configuration read does not carry them.

Decisions you make here

Reading the group

Each card shows its subsystem's label, a one-line purpose and a badge. The two connector cards, HSM / Cloud KMS and Timestamping (TSA), carry a status badge — Active, Attention, Not configured, Unknown, Not applicable or Restricted — rather than a count, and the timestamping badge adds how many trust anchors are loaded. Unknown means no answer arrived and Restricted means an answer exists that your permissions do not admit; neither is a statement about the integration itself.

Token signing keys and Projection signing keys carry no badge: they hold keys, not configuration values.

Projection signing and Migration & Trust carry a plain count instead. The group holds 99 configuration values in all: 86 under HSM / Cloud KMS, 7 under Timestamping, 1 under Projection signing and 5 under Migration & Trust. The Posture filter above the list narrows every count on the page at once to Editable, Read-only or Secrets, so a badge reading 0 under a filter is a filtered count and not an empty subsystem.

Changing a value, and when it takes effect

A value opens an edit panel built from its own validator: an enumerated value offers its choices, a bounded number rejects out-of-range input before you can save, and the server is asked to validate the candidate before Save becomes available. A value classified dangerous also requires you to type its key exactly. Nothing is saved until the server has accepted the candidate; the client check never substitutes for it.

Most values in this group apply immediately — the change is published to the services that read it and is live on the next operation, with no restart. A value that binds at start-up instead marks itself pending and raises a Restart required banner that names the count and, when the platform knows it, the command that applies it. The banner never clears by itself, and the Pending Restarts view lists exactly what is waiting.

Migration & Trust

Five values govern what the platform accepts when key material is imported from another system:

Certificate validation mode — STRICT by default, with IMPORT_ONLY and SKIP as the relaxed poles. This is the trust decision taken on every certificate inside an imported keystore. The relaxed poles accept material whose issuer was never verified, and the resulting key is afterwards indistinguishable from one that was verified: the import record does not carry the doubt. Dangerous, and live without a restart.
Allow mode override — off by default. On, the caller of an import chooses the strictness rather than the deployment, so the value above becomes advisory. Dangerous, and live without a restart.
Maximum keystore size — 20 MiB by default, bounded between 1 MiB and 100 MiB. The check runs before the upload is read into memory, so this ceiling is the only thing bounding how much one import can buffer. Live without a restart.
Trust anchors path — the directory the migration trust anchors are read from, shown read-only. It is owned by the deployment, not by this screen.
Revocation checking during migration — the screen states, in the entry itself, that nothing in the settings plane reads this key, so a value saved here does not reach the validator. It records the deployment flag rather than operating it, and the entry names the environment variable that does act.

How it relates to other screens

The subsystems in this group that administer records rather than values each have their own page:

Whether a tenant must, may or may not stamp a signature is a policy decision and is not made here; the integration map draws both subsystems beside the rest of what your installation is connected to: