Organization CA

The Organization CA is the per-organization certificate authority that signs managed-database TLS leaves. It is distinct from the instance-wide Platform CA that daemons use to trust the control plane.

Not the Platform CA

There is one active Organization CA per organization. It is never shared across organizations. For the other CA — the instance-wide root daemons pin — see Daemon trust model → Platform CA rotation.

What it is

Each organization has one active Organization CA: a tls row with source='organization_ca'. A rotation mints a new active generation and keeps the previous generation in the trust bundle as retired until operators explicitly retire it. Organizations never share a CA; a leaf issued for one org is not trusted by another org's bundle.

Newly minted Organization CAs use a unique subject distinguished name:

O=TurboPanel, OU=Organization CA, CN={organization id}

The common name is the organization UUID so two orgs never share an Organization CA distinguished name. Branding lives in O / OU.

What it signs

The Organization CA signs the leaves that terminate managed-database TLS:

ProxySQL frontend leaves (the advertised client listener)
Managed engine listener leaves
Replication leaves (sslmode=verify-full / MySQL-family REQUIRE SSL)

Topology — who dials whom, SANs, and the ProxySQL hostgroup model — lives in Managed database ingress. This page does not re-explain that stack.

How clients obtain it

Operators and apps retrieve the Organization CA as PEM text, never as a private key and never as a filesystem path:

Channel	Detail
Console	Connect → Download CA certificate
API	`GET /api/client/v1/tls/ca/download`
Bindings	Materialized `<PREFIX>_CA_CERT` environment variable (PEM text; the consuming app writes it to a file if the driver requires a path)

The download is the trust bundle: the active generation plus any retired generation still in overlap. Private keys never cross the client API.

Rotation runbook

Rotation uses the same rotate-before-retire order as the Platform CA. Do not retire first: clients and daemons still on the outgoing generation must keep a trusted chain while new leaves are issued.

Rotate — POST /api/client/v1/tls/ca/rotate mints a new active generation. The previous active generation becomes retired but stays in the trust bundle.
Overlap — fan-out re-issues ProxySQL and engine leaves under the new generation and rematerializes bindings so <PREFIX>_CA_CERT carries the updated bundle.
Confirm — GET /api/client/v1/tls/ca/rotation until every tracked command is terminal-success.
Retire — POST /api/client/v1/tls/ca/retire drops the old generation from the bundle. The control plane refuses with 409 until overlap has converged.

A leaked key: what to do, and what it costs

There is no CRL and no OCSP responder. Neither CA publishes a revocation endpoint, and revoke in the API is a database status flip — it stops TurboPanel handing that certificate out, and does nothing to a client that already holds it. So the honest answer to a compromised key is rotation, and the cost depends on which key it was.

What leaked	Answer	Collateral
An Organization CA leaf (a ProxySQL or engine certificate)	Rotate the Organization CA with the runbook below	Every leaf in that organization is re-issued, and `verify-ca`/`verify-full` clients re-download the bundle. Bounded: leaves live 90 days and the sweep renews at a third remaining, so an un-rotated leak expires on its own inside a quarter — rotation is how you make that immediate, not how you avoid an indefinite exposure.
An Organization CA private key	Rotate immediately, then retire the old generation as soon as overlap converges	Same fan-out, but the old generation must not linger in the bundle: while it does, anything signed by the leaked key is still trusted.
The Platform CA	The daemon trust model's own rotation — see Daemon trust model	Every daemon re-trusts; do not retire before the fleet has converged.

CA roots are minted for 10 years and leaves for 90 days. The long root is what makes retire-after-overlap safe; the short leaf is what bounds a leak you have not noticed yet.

Rehearse this before you need it: run the runbook below on a non-production organization once, and time it. The step that takes real time is overlap convergence, and that is the step an incident will not let you skip.

Automatic leaf renewal

Issued leaves are tracked in the leaf table (signing Organization CA, generation, not-after). A leaf is due when:

remaining lifetime is less than one third of the issued lifetime, or
its ca_generation no longer matches the active Organization CA generation (rotation).

A bounded, cursor-driven sweep renews due leaves and fans the same apply / ingress reconcile path as operator rotation.

Client-impact checklist

Client TLS mode	After Organization CA rotation
`verify-ca` / `verify-full`	Re-download the trust bundle. Redeploy binding-consuming environments so `<PREFIX>_CA_CERT` refreshes. Until both happen, drivers that pin the old PEM will fail handshake.
`require` and lower	No client action. The ingress cert chain stays trusted through the overlap bundle; the server still presents a valid leaf.

Non-goal

Hosting is separate: tenant hosting leaves (Caddy-fronted web services) are operator-pinned library certificates, Caddy tls internal, or a Let's Encrypt row Caddy issues on the serving host (tlsMode: acme). They are never issued by the Organization CA. See Hostnames and TLS.

On this page