Skip to content

fix/workaround: allow external/alternative CAs for the client commands when using TLS.#113

Open
margau wants to merge 1 commit intovalkey-io:mainfrom
margau:feat/cacert
Open

fix/workaround: allow external/alternative CAs for the client commands when using TLS.#113
margau wants to merge 1 commit intovalkey-io:mainfrom
margau:feat/cacert

Conversation

@margau
Copy link

@margau margau commented Jan 5, 2026

Recently, I ran into a problem with TLS certs:

I'm using a TLS Cert by cert-manager using ACME. In the secret generated with cert-manager, there is no separate CA available (see the topics on ca.crt in https://cert-manager.io/docs/usage/certificate/#target-secret).

Therefore, I needed a separate way of using another CA for the valkey-cli client (mainly for probes).

This PR adds a value that allows the client to use any other ca.

In my case the cacerts provided by trust-manager into a config map and mounted using the extraValkeyConfigs.

Using the fullchain aka tls.crt, which is provided to the server as ca file from the TLS-secret, does not work:

I have no name!@valkey-76d9f8db58-fp6bh:/data$ valkey-cli --tls --cacert /tls/tls.crt
Could not connect to Valkey at 127.0.0.1:6379: SSL_connect failed: certificate verify failed
not connected> 
I have no name!@valkey-76d9f8db58-fp6bh:/data$ valkey-cli --tls --cacert /cacert/trust-bundle.pem 
127.0.0.1:6379> 

Given the above example, setting tls.alternativeClientCa: "/cacert/valkey-trust-bundle.crt" should make it work also for the probes.

/cacert/ is the mount of trust-manager, which creates a configmap with all CAs necessary, e.g. using the following bundle:

apiVersion: trust.cert-manager.io/v1alpha1
kind: Bundle
metadata:
  name: valkey-trust-bundle
spec:
  sources:
  - useDefaultCAs: true
  target:
    configMap:
      key: "trust-bundle.pem"

Please let me know in case there is a better way solving this.
Thanks!

Signed-off-by: Vanessa Gaube <dev@vanessagaube.de>
@sgissi
Copy link
Collaborator

sgissi commented Jan 15, 2026

Hi @margau, thanks for the PR. I understand the principle, CAs sometimes has to be provided outside of the TLS secret. The only concern I have is that the logic of using an alternate path is spread across many places, and it will only grow after Sentinel/Cluster is implemented. I believe the exporter sidecar will also need handling. I would rather add the logic in _helpers.tpl (e.g. define "valkey.caFile") and use that value in the rest of the code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants