# CA trust best practices In the Juju ecosystem, multiple TLS providers can be used to issue certificates for applications and units: - [self-signed-certificates](https://charmhub.io/self-signed-certificates) - [Vault](https://charmhub.io/vault-k8s) - [Lego](https://charmhub.io/lego) - [manual-tls-certificates](https://charmhub.io/manual-tls-certificates) - [Notary](https://canonical-notary.readthedocs-hosted.com/en/latest/) In many cases, the CA certificates used by these providers are self-signed or private. This means that the certificates they issue will **not** be trusted by default by other applications or clients unless the CA is explicitly trusted. ## Trust establishment between clients and applications For TLS to work correctly: - Clients must **trust the CA** that issued the application’s leaf certificate. - Applications must present a **valid chain** that leads to that trusted CA. ### Public CAs When using a public CA through `lego` (e.g., Let’s Encrypt), certificates are usually trusted by default by most clients and browsers. ### Private or self-signed CAs When using `self-signed-certificates`, `vault`, `manual-tls-certificates`, or `notary`, clients (or client applications) must explicitly trust the CA. For Juju-integrated client applications, this is achieved by integrating with the provider over the `certificates-transfer` interface. ## Best practices for production deployments ### Internal communication (unit-to-unit) As described in the [securing internal communication](securing-internal-communication.md#securing-internal-communication) guide, `self-signed-certificates` can be used to secure intra-application traffic. In this case: - Each unit of an application receives the CA certificate as part of the relation data from the `tls-certificates` integration. - The CA is the **direct issuer** of the application’s leaf certificate. - **Trusting this CA is sufficient** to establish trust in the leaf certificates. ### API communication For more complex deployments that [secure API communication](securing-api-communication.md#securing-api-communication), client applications should trust the CA **directly from the CA provider**, not from the application serving the certificate. - The CA certificate can be obtained by integrating with the provider over the `certificates-transfer` interface. - When the provider uses an intermediate CA, it is recommended to trust the **root CA** (or the highest CA in the hierarchy). ### Cross-model CA distribution In multi-model deployments, a CA that issues certificates in one model is not automatically trusted in another. Trust must be established explicitly by sharing the CA certificate across model boundaries. This is done via the `certificate-transfer` interface over a cross-model relation. The model that owns the CA **offers** it; the consuming model **consumes** it and imports the CA certificate into the trusting application’s store. Each `certificate-transfer` represents an explicit trust decision: Model B is choosing to trust certificates issued by Model A’s CA. In a per-model CA topology, these decisions should be made deliberately and kept to the minimum required for the application to function. See [multi-model TLS reference architectures](../deployment-blueprints/multi-model-tls.md#multi-model-tls) for complete architectures showing how to structure cross-model TLS in production deployments. ### Summary | Scenario | Trust source | Interface | |-------------------------|-----------------------------------------------|-------------------------| | Internal (unit-to-unit) | CA cert from `tls-certificates` relation data | `tls-certificates` | | API (client-to-server) | CA cert directly from the provider | `certificates-transfer` | | Intermediate CA | Root CA (recommended) | `certificates-transfer` | | Cross-model | CA cert via `certificate-transfer` | `certificate-transfer` |