Security 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.

Contents:

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 already supports the tls-certificates interface.

At the application 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 requirer side of the tls-certificates-interface in your charm. A typical example is enabling various units of a PostgreSQL cluster to communicate via TLS.

The upcoming questions will help you choose the most appropriate TLS provider for a TLS connection terminated at application level.

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 LEGO 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 manual-tls-certificates operator, which supports actions to list certificate requests, retrieve signing requests, and supply manually obtained certificates.

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

The tls-certificates charm integration interface is used by charms providing and requiring X.509 certificates. The tls-certificates-interface library is used to handle most of this heavy lifting for both requirers and providers of the tls-certificate integration.

As we saw on question 1, if your TLS connection should be terminated at the application level, the requirer side of the tls-certificates integration needs to be implemented in your charm. Then, you just need to integrate your charm with the TLS provider operator of your choice, according to your answers to questions 2 and 3.

For more information about implementing this library in your charm, look at the documentation.

Still have questions?

Meet the community and chat with us on Matrix.


Last updated 2 months ago.