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.
- Understanding your X.509 certificates requirements
- (For charm authors:) Implementing the tls-certificates relation in your charm
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?
- Question 2: What type of certificates do you need?
- Question 3: How do you get your signed certificates ?
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.
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.
Essential for most production deployments. If this applies to you, proceed to question 3.
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.
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.
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.
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.
Last updated a month ago.