Status, on the record
Operational checked 2026-08-14 · live answer at /v1/status
This page is the human-readable sibling of the machine-readable status endpoint. It also carries two things a status page usually dodges: exactly who holds the signing key today, and what a Redeal outage does and does not mean.
Who holds the signing key
- scheme
- ECDSA P-256 (es256) — every certificate signature verifies against the published public key.
- public key
- es256:037ecf680d2b5dc2589b38dfb3b5a0ebc834eb4cbe26c88e48efc0d0be82ed97cb
served live at GET /v1/status; pin it yourself if you verify at scale - custody
- AWS KMS (Stockholm region), used sign-via-API since the first deployment: the server can request signatures but can never hold or export the key, and every signing call is logged by AWS. There are no open custody caveats.
Incidents and key rotations
| date | event |
|---|---|
| 2026-08-11 | First public deployment, signing key held in AWS KMS from the first certificate. No incidents. No key rotations. |
Empty is the goal. Any incident or rotation gets a dated row here, never a quiet fix.
What an outage would mean
Very little, for certificates that already exist. A Redeal certificate carries its signature and its Merkle inclusion proof; both verify offline against the public key above and any tree head you already hold. If redeal.dev disappears tomorrow, every issued certificate still checks out.
What stops during an outage is new work: no new deals, no new tree heads, no /v1/verify lookups by ID. Trust in Redeal was designed never to depend on Redeal being up.