I’m trying to configure public networking with a certificate signed by letsencrypt, using cert-manager. But the certificate is required to have a number of local SANs, which letsencrypt won’t allow (error: Domain name does not end with a valid public suffix (TLD)). What’s the process for generating a TLS certificate signed by a trusted CA with both public and local DNS names?
I’m also trying to figure out how the operatorSecret fits into this. My understanding is the server certificate should descend from this operator CA certificate. But how can I have a trusted CA sign my public server certificate if I need my own self-signed CA certificate?
Also, cert-manager saves certificates in the TLS secret format, with certificate named tls.crt and private key named tls.key. What’s the best way to handle passing this secret to Couchbase, which expects the certificate to be named chain.pem and private key pkey.key?
It’s almost like you are mind reader…
Operator 2.2 (coming soon!) realizes the historical mistakes we made and does support kubernetes.io/tls type secrets, specifically those created by cert-manager, we handle the marshaling into the correct format for you. Just to delve a little bit deeper. Couchbase server expects certificates to be passed in as chain.pem/pkey.key, and it’s hard coded, so our hands are tied in that respect, however in future we will offer a translation layer that reformats into a “shadow” secret that conforms to those limitations.
TLS is more interesting, unsurprisingly. We operate in TLS passthrough mode (e.g. L4 load balancers at the edge). This has the benefits of simplifying configuration, and offering full end-to-end encryption. As such the certificate needs to work for both public and internal traffic, which is where your problem stems from.
Now could we terminate TLS at the edge and allow certificates from a public CA? Probably from a technical standpoint.
The difficulty then becomes reestablishing TLS between the load balancer and the cluster. This is all very platform/provider specific, so really complex to test and document in a platform agnostic manner. We’ll probably get around to seeing if this model works in the 2.3 time frame (you’re not the first!) You may be able to do this today, services are effectively templated, so you can do what you want. In this instance, set the type to LoadBalancer, add in the necessary annotations to make it use your public certificate, then somehow give it access to the cluster CA to re-establish TLS (there is no way to do port translation yet from TLS to plaintext… there is always TLS no verify on the back end if you are desperate - ugh, I said it).
Short term, the simple answer is to sign your own certificates and distribute the CA to your clients.
Thanks, glad to see this is on your radar. And thanks for the explanation. Looking forward to these changes in 2.2 and 2.3. In the meantime, we’ll work with distributing certificate to clients.
Also, I dropped you a note here about fixing a typo in the CRDs in the helm chart.
Cheers! Yeah I spotted this a month ago, it’ll be in 2.2.
1 Like