Charm should have the option to provide externally issued certificates

[dparv]

Enhancement Proposal

Right now if you provide a certificate from, let's say letsencrypt, you can't use it as you can't obtain the CSR. It would be nice to have an action that will take the certificate, key, ca-certificate and assign it to a relation id, overriding the issued CSR by the charm.

[gruyaume]

Hello @dparv,

The whole idea with the tls-certificates integration is for private keys to not move around, hence why it stays in the charm requesting the cert and is never shared.

Let's Encrypt allows certificates to be generated from CSRs. Depending on your DNS provider, we encourage using one of the Let's Encrypt charms (instead of Manual TLS Certificates) for those use cases:

• Route53 LEGO K8s
• Namecheap LEGO K8s
• HTTPRequest LEGO K8s

All of them provide certificates through the same tls-certificates integration.

[dparv]

Hello @gruyaume,

Fair enough from a security point of view.. but that's a user preference at the end, no? In a situation where you can't have DNS ACME challenges and you need HTTP challenges, but the charms don't support them (e.g. traefik-k8s or istio-gateway) there is the need to provide manually the certificates. For traefik-k8s there are juju config options, e.g. tls-key, tls-cert, tls-ca - which is a workaround, but for kubeflow with istio-gateway/istio-pilot there is no way to do this. So the only way to move forward is to have a charm that can at least give the option to the user to add manually certificates if there is no other way. HTTPRequest LEGO K8s also doesn't work in this case, as the actual FQDN/IP address is owned by the traefik-k8s or istio-gateway charms and they are the ones that need to respond to the ACME HTTP challenge.

[dparv]

@gruyaume bump?

[gruyaume]

Hello @dparv , we have a task to spend some time and understand your request, and hopefully come up with a satisfying solution for you. Hopefully we get to it in the next week or two.