Secure your charm deployments with X.509 certificates

X.509 certificates are vital in the security of many Internet protocols, including TLS/SSL. If your charm workload communicates over HTTPS, you most likely need these certificates. Within the Juju ecosystem, the tls-certificates charm relation interface handles X.509 certificate creation, renewal, and revocation.

Understanding your X.509 certificates requirements

To meet your X.509 certificate needs, start by answering the following questions. Your answers will help you decide whether you need to implement the tls-certificates interface in your charm and which TLS provider to use.

Question 1: Where should your TLS connection be terminated?

At the ingress level

In contexts where X.509 certificates are necessary to ensure HTTPS communication with users or systems outside of the Juju model where the application is deployed, it is recommended to use an ingress controller like Traefik. Traefik handles TLS connection termination, sending decrypted data to your application, so your application charm does not need to manage X.509 certificates. Implementing the ingress integration is all that’s required as Traefik supports the tls-certificates interface.

At the app level

For use cases where HTTPS communication is done inside of the Juju model, TLS connections will need to be terminated at the application level. This requires implementing the tls-certificates interface in your charm. A typical example is enabling various units of a PostgreSQL cluster to communicate via TLS.

Question 2: What type of certificates do you need?

Signed Certificates

Essential for most production deployments. If this applies to you, proceed to question 3.

Self-signed certificates

Ideal for development and non-production environments. In these cases, look no further. The self-signed-certificates operator provides self-signed certificates in the charm ecosystem. Upon deployment, the self-signed-certificates operator generates a private key and a Certificate Authority (CA) certificate (that is not signed by any authority). The operator signs each certificate request it receives using this self-signed CA certificate.

If this applies to you, ignore question 3.

Question 3: How do you get your signed certificates ?

Using Let’s Encrypt (or another ACME server)

Utilize the ACME charm operator specific to your DNS provider to request certificates using the ACME protocol. We currently maintain:

The ACME server will validate domain ownership using the DNS-01 challenge. If your DNS provider is not supported, let us know and we can help support it. For more information about using the Let’s Encrypt operators in your charm, read this post.

Through a manual process

If your organization has a manual process for managing certificates, consider the tls-certificates-operator, which supports actions to list certificate requests, retrieve signing requests, and supply manually obtained certificates.

Implementing the tls-certificates relation in your charm (for charm authors)

The tls-certificates charm relation interface is used by charms providing and requiring X.509 certificates. Requirers of TLS certificates generate their private key as well as a Certificate Signing Request (CSR) and insert this CSR into their unit application data. On the other side of the relation, the TLS certificate provider will read this CSR, generate (or request) a certificate and insert this certificate into its application relation data.

The tls-certificates-interface library is used to handle most of this heavy lifting for both requirers and providers of the tls-certificate integration. This library contains the TLSCertificatesRequires and TLSCertificatesProvides Python classes for handling the tls-certificates interface. For more information about implementing this library in your charm, look at the documentation.

Last updated a month ago.