Skip to content

Key-State Seal Key

What this screen is for

Key-state seal key shows the key that seals every key record of this deployment, and lets a platform super administrator rotate it after a suspected exposure.

Every key record carries a seal computed over the fields that decide how the key may be used: its tenant, purpose, status, algorithm, limits and expiries. A record whose seal does not verify is never used. The platform generates the seal key and holds it wrapped by the deployment's key-encryption key; it never appears at your key-protection provider.

You do not have to do anything here in normal operation. A rotation is for the day you suspect the seal key itself was exposed.

What must exist first

  • You work in the platform context.
  • Reading the screen needs the platform observability read permission, held by every platform role. Without it the screen says it cannot be read.
  • Rotate seal key and Reopen need their own permission, held only by the built-in platform super administrator. Without it neither action is offered, and neither is offered while you are working inside a tenant through support access.
  • The rotation and the reopen ask you to confirm your identity again when your sign-in is not recent.
  • A bound key-protection backend that can wrap the new key. While it cannot, the rotation is refused and nothing changes.

Decisions you make here

Reading the generations

Each row is one generation of the seal key, newest first:

  • Active — the key that seals every record written now.
  • Previous — the key a rotation replaced. It still verifies the records that have not been moved to the new key yet.
  • Retired — a key no record names any more. Its key material is erased; only its identifier and its history remain.

The Proof column says whether the platform still proves the generation against your key-protection backend: Open, or Closed with the reason and since when.

When the seal key is closed

The platform keeps proving the Active generation. When the proof fails it closes the generation, and while the Active generation is closed every key write is refused on every tenant. The screen shows this as an alert above everything else, with the reason:

  • Backend refusals — your key-protection backend refused the proof twice, at least five minutes apart. Nothing about the key is in doubt. The generation reopens by itself on the next successful proof, so check that the backend is reachable and accepts the platform's requests.
  • Mismatch — the key did not prove: it is not the key the records were sealed with. This closure stays until a super administrator lifts it, by a reopen once the mismatch is explained, or by a compromise rotation when the key may be exposed.

Reopening a generation

Reopen is offered on an Active or Previous generation closed by a mismatch, and on no other. You state why the mismatch no longer stands, for example a backup restored to the wrong key that was then put right; the reason is recorded on the platform audit trail. Key writes are admitted again as soon as the reopen succeeds.

Reopen only when the cause is explained. If the key may have been exposed, rotate it in compromise mode instead.

Rotating the seal key

Rotate seal key creates the next generation, makes it Active and turns the current one into Previous. A pass then moves every key record to the new key, table by table. A record whose seal does not verify is never moved: the pass names it and stops short of retiring the old key.

You give a reason, which is recorded on the platform audit trail. Only one rotation runs at a time; while a Previous generation is held, or a pass is running or blocked, a new rotation is refused and nothing changes. While the Active generation is closed by a mismatch, only a compromise rotation is admitted, and the dialog turns compromise mode on for you.

Compromise mode

Tick The seal key may have been exposed when you rotate because of an exposure. Until the pass moves a record, every key whose record is still sealed under the old key is refused at use, so keys can be unavailable for the length of the pass. Plan it for a quiet period.

Compromise mode cannot detect every forgery. After the rotation, compare the keys you are concerned about with their audit history.

Following the pass

The progress panel shows, for each of the three key tables, how many records were already current, were moved, were held by another write and will be retried, are waiting for the key-protection backend, are waiting for the material they belong to be moved first, or were refused.

During a compromise rotation the pass needs to read which records are safe to move. While it cannot, the panel says so and since when; the pass then waits on those records and refuses none.

When a mismatch closes the previous key during a rotation

If the platform's proof closes the Previous generation on a mismatch while an ordinary rotation is running, the old key can no longer verify the records still sealed with it. The rotation then becomes a compromise rotation, and the panel says when. Two things follow:

  • The records not moved yet are re-sealed on their signed version floor alone. The panel counts them per table, apart from the records moved normally, and states the limit: their integrity rests on that floor, which signs each record's version and not its content.
  • A record the pass refused before the conversion stays refused, so the pass can still end Blocked with that record listed.

Until every signed version floor is complete, the conversion waits: the panel says since when, nothing is re-sealed and the pass does not block. Reopening the previous key once the mismatch is explained ends the wait. A conversion that has happened is not undone by a later reopen.

  • Running — the pass is moving records.
  • Blocked — at least one record did not verify. The panel lists each one by table and identifier, and nothing about them is changed. Investigate them against the key's audit history.
  • Complete — every record names the new key and the old generation is retired.

The step-by-step procedure, including what to do after restoring a backup taken before a rotation, is the key-state seal key rotation runbook in the operations section of the customer documentation.

How it relates to other screens

The backend whose key-encryption key wraps the seal key, and the other key sets of this group:

Where to read more