Add a generic Core-managed internal CA certificate provider

[cassi-volkova]

Problem

Internal services need hostname-verified TLS without depending on a public ACME challenge. Today, consumers may generate private certificate bundles during image builds, which fragments CA ownership, rotation, trust distribution, and migration behavior across products.

Proposed capability

Add a generic internal_ca certificate method to Core Secret Manager:

• generate and retain a private CA key in the certificate backend;
• expose only the public CA certificate as ca_cert;
• issue leaf server certificates with DNS SANs and a full leaf-plus-CA chain;
• reuse the CA for normal leaf renewal;
• rotate the CA before a newly issued leaf could outlive it;
• reconcile key, cert, ca_cert, and expiration state through the existing certificate resource workflow;
• never expose the CA private key through the user API or rendered manifest data.

Security requirements

• Keep CA private keys server-side with access controls equivalent to other stored private keys.
• Ensure API field permissions prevent clients from supplying or reading private CA key material.
• Use modern key sizes, SHA-256 signatures, CA basic constraints, server-auth extended key usage, and DNS SAN validation.
• Define operational expectations for CA rotation, overlapping trust, backup/restore, and auditability.
• Document that consumers must distribute ca_cert only to trust stores and leaf key/cert only to the owning service.

Persistence and migration

The schema needs nullable fields for the public CA certificate on certificate resources and the CA key/certificate in backend storage. The migration must be backward-compatible for existing public ACME certificates and support upgrade from the current released schema.

Consumer migration from build-time private certificates should use an overlap period:

1. create the Core-managed internal_ca certificate resource;
2. distribute the new CA certificate to clients while retaining trust in the old CA;
3. deploy the Core-issued leaf certificate to the service;
4. verify hostname validation and renewal behavior;
5. remove the legacy build-time CA only after all clients have converged.

Acceptance criteria

• Unit coverage verifies certificate signatures, DNS SANs, CA reuse, leaf renewal, and CA rotation threshold behavior.
• Functional coverage verifies API acceptance and service reconciliation of ca_cert.
• Migration coverage verifies upgrade from the released schema and preservation of existing certificate rows.
• Documentation describes consumer trust distribution and rotation responsibilities.
• A consumer migration issue tracks removal of Workspace build-time certificate generation after this capability is production-ready.

This capability is for future adoption and must not be treated as authorization to update an existing live Core installation.

[cassi-volkova]

Consumer migration tracking: exordos/workspace_backend#18 documents the current build-time internal mail TLS bundle and the future overlapping-trust migration to this Core-managed capability. The implementation remains draft-only in #490 and is not intended for a current live deployment.