The problem/use-case that the feature addresses

I'm trying to connect to my redis-server, which has TLS enabled, with a self-signed certificate. Following these docs, I have tried passing it to the redis-cli: redis-cli -h <hostname> -p <port> -a <password> --tls --cacert my-self-signed-cert.pem

The response I get:

Could not connect to Redis at \<host>:\<port>: SSL_connect failed: certificate verify failed

My redis.conf file setting up the certificate & key, and disabling client authentication:

port 0
tls-port 6379

tls-cert-file /ssl/my-self-signed-cert.pem
tls-key-file /ssl/key.pem

tls-auth-clients no

Description of the feature

I want to be able to pass my self-signed certificate to the --tls --cacert flag, and have it connect via TLS.

Taking inspiration from this Redis client for Golang which utilises a TLS Config struct, here I can tell it to accept any certificate presented by the server by using a simple flag:

// InsecureSkipVerify controls whether a client verifies the server's // certificate chain and host name. If InsecureSkipVerify is true, crypto/tls // accepts any certificate presented by the server and any host name in that // certificate. In this mode, TLS is susceptible to machine-in-the-middle // attacks unless custom verification is used. This should be used only for // testing or in combination with VerifyConnection or VerifyPeerCertificate. InsecureSkipVerify bool

This could maybe be done for redis-cli by setting a insecure-skip-verify flag in cli.

Alternatives you've considered

A different redis client.

Additional information

My redis server is correctly configured with TLS, as I can connect to it via the GoLang redis client I've mentioned above.

➜ redis-cli --version
redis-cli 6.0.9

Comment From: yossigo

@eFuller96 What you're describing should work, as long as it's the same self-signed cert used by Redis as a --tls-cert-file and redis-cli --cacert. If that doesn't work, it could also be an issue with the certificate itself - how did you generate it?

Comment From: eFuller96

@yossigo you were right - it was being signed incorrectly and now works. Thanks.

However I still think this issue stands - it'd be nice to have a flag to bypass providing a valid certificate - other database engines offer this, e.g. Mongo

Starting in MongoDB 4.0, if you specify --sslAllowInvalidCertificates or net.ssl.allowInvalidCertificates: true (or in MongoDB 4.2, the alias --tlsAllowInvalidateCertificates or net.tls.allowInvalidCertificates: true) when using x.509 authentication, an invalid certificate is only sufficient to establish a TLS/SSL connection but is insufficient for authentication.

Comment From: yossigo

@eFuller96 I agree it's a useful feature.