[tialaramex]

Given that Redis is not known for being something that's only deployed by security-savy people I expect their line:

> In addition, it is necessary to specify a CA certificate bundle file or path to be used as a trusted root when validating certificates.

... will not cause many real users to do what they actually need to do here. That's certainly the experience with lots of software that has this sort of feature. Users tend to fill this out with the CA certificate corresponding to the server. Now, if what you've done is spin up your own CA just for Redis, mint a certificate for the server and then you're going to do the same for all clients this could work (it'd be weird but it could work) but just as likely you'll use a nice Let's Encrypt certificate for the server - and now you're telling the server "By the way, anybody with a Let's Encrypt cert is trusted as a client". This is, let's say, very unlikely to be what you actually wanted.

(Edit: Clarified text above somewhat)

[imtringued]

>(it'd be weird but it could work)

This is how it works with zookeeper and kafka as well. I don't know why those projects are such a pain in the butt but I certainly don't want to learn two completely different over complicated authentication systems when all I really wanted is the ability to set a password. I'll just use TLS for authentication and be done with it.

[tetha]

Seems to be fairly standard indeed - elastic, mysql, postgres, .. all do the same thing. If reloading works properly, our hashicorp vault-based TLS stack could handle that out of the box including aggressive rotation.

TLS authentication isn't that hard once you understand the fundamentals.