TLS Certificates Interface
| Channel | Revision | Published | Runs on |
|---|---|---|---|
| latest/edge | 172 | 26 Aug 2025 | |
| latest/edge | 19 | 10 Feb 2023 |
juju deploy tls-certificates-interface --channel edge
Deploy Kubernetes operators easily with Juju, the Universal Operator Lifecycle Manager. Need a Kubernetes cluster? Install MicroK8s to create a full CNCF-certified Kubernetes system in under 60 seconds.
Platform:
Trust CA certificates of TLS Providers
In the Juju ecosystem, multiple TLS providers can be used to issue certificates for applications and units.
In some cases, the CA certificates used by these providers are self-signed. This means that the certificates they issue will not be trusted by default by other applications or clients unless the CA is explicitly trusted.
Best Practices for Production Deployments
- Internal Communication (Unit-to-Unit)
As described in the internal communication guide,
self-signed-certificatescan 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, client applications should trust the CA directly from the CA provider, not from the application.
- The CA certificate can be obtained by integrating with the provider over the certificates-transfer interface.
- When the provider uses intermediate CA, it is recommended to trust the provider with the root CA (or the highest CA in the hierarchy). However this is not mandatory.