Redis Sentinel ignores TLS configured via rediss://

Issues
1

Issue Description

When RedisSentinel is configured with rediss:// URLs, Stalwart connects to both the Sentinel nodes and the discovered Redis master using plain TCP.
Credentials configured through authSecret and sentinelSecret work, but the connections are not encrypted. This makes Redis Sentinel unusable when Sentinel and Redis nodes require TLS.

Expected Behavior

rediss:// enables TLS for both Sentinel and Redis data-node connections.

Actual Behavior

both connections use unencrypted TCP.

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

PostgreSQL

Blob Storage

S3-compatible

Search Engine

Elasticsearch

Directory Backend

Internal

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Looking at the current source, this is confirmed as a real bug in the Redis Sentinel implementation, not just a documentation gap.

In open_sentinel() (crates/store/src/backend/redis/mod.rs), each Sentinel URL is parsed only to extract its addr() (host/port) via into_connection_info(), and the resulting plain socket addresses are handed to SentinelClientBuilder. The rediss:// scheme, which carries the “use TLS” signal, is discarded at that point, so neither the Sentinel connections nor the discovered master connection ever get a TLS context — unlike the single-node (RedisStore::open_single) path, which builds Client::open(config.url) directly and does honor rediss://.

So your observation is accurate: TLS configured via rediss:// is effectively ignored for Sentinel-mode deployments in the current code.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Fixed in v0.16.20 (yet to be released).