Operator · Your Own Certificate

Serve From Your Own CA

Frame 20 of 107

You built a root and an issuing CA in First Run. Time for the satisfying part: make goca serve its own console from your hierarchy.

The system template goca-service-tls always exists and cannot be deleted; the supported operation is re-binding. Open it in the template editor (it shows a system note), change issuerRef from ica-infra to your issuing CA, and save — an ordinary new template version. Every goca process re-issues and hot-swaps its serving certificate within about a minute, with no restart and no dropped connections. Clients now chain to your root.

The server holds three lines on this template: approval is locked to auto — a renewal loop that can wait for a human will one day take HTTPS down with it; it cannot become a derived template; and ica-infra stays reserved — no other template may bind it, no endpoint may expose it.

And if a policy edit refuses a name, the name is dropped, not fatal: goca will not take its own console offline over a typo.

Pick a classical CA. Any CA bound to goca-service-tls must sign with a classical algorithm — ECDSA, RSA, or Ed25519 — because browsers and TLS stacks cannot yet verify PQC chains. The server refuses a PQC or composite CA here; your customer CAs stay unrestricted.

Now I can put my own hierarchy behind every goca listener with one template save.