Last checked and updated on 28 Apr 2026What Is New in Jedis 7.5
Jedis 7.5 tightens TLS handling and starts moving TLS configuration toward a single, unified API via SslOptions. The headline change is hostname verification now being on by default for the legacy ssl(true) path -- something that was previously a gap developers had to close manually.
| Category | Change | Impact |
|---|---|---|
| Security | Hostname verification enabled by default on legacy TLS path | High -- connections to hosts with mismatched SAN/CN will now fail |
| Deprecated | Legacy ssl(true) SSL configuration |
Medium -- still works, but migrate to SslOptions |
| Behaviour Change | SslOptions-based config remains unchanged |
Low -- no action needed if already using SslOptions |
How Does Hostname Verification Change TLS Behaviour in 7.5?
Before 7.5, using the legacy ssl(true) flag opened a TLS connection but skipped hostname verification -- meaning the client would accept a certificate even if its SAN or CN did not match the actual host you were connecting to. That silent gap is now closed.
Starting in 7.5, the legacy TLS path rejects certificates whose SAN or CN does not match the target host. In practice, if your Redis server uses a self-signed cert, an internal CA cert without a proper SAN, or a wildcard cert that does not cover the specific hostname -- your connection will fail where it used to succeed.
The SslOptions-based path is unaffected; its behaviour has not changed. If you are already wiring TLS through SslOptions, 7.5 is a non-event for that code path.
Checking Whether You Are on the Legacy Path
If your Jedis client setup looks like either of these, you are on the legacy path and need to verify your certificate setup before upgrading:
// Legacy path -- hostname verification now enforced
JedisPool pool = new JedisPool(new JedisPoolConfig(), "redis-host", 6380, 2000, "password", true);
// Also legacy
JedisClientConfig config = DefaultJedisClientConfig.builder()
.ssl(true)
.build();
If your setup uses SslOptions explicitly, you are already on the modern path:
SslOptions sslOptions = SslOptions.builder()
.truststore(...)
.build();
JedisClientConfig config = DefaultJedisClientConfig.builder()
.sslOptions(sslOptions)
.build();
What Is Being Deprecated and What Should You Migrate To?
The legacy SSL configuration -- primarily the ssl(true) boolean and related constructor/builder overloads -- is now officially deprecated in favour of SslOptions. It still functions in 7.5, but plan to migrate before it is removed in a future major release.
Migration Pattern
Move from the boolean flag approach to constructing an SslOptions instance. This gives you explicit control over trust stores, key stores, and hostname verification settings rather than relying on implicit defaults.
// Before (deprecated)
JedisClientConfig legacy = DefaultJedisClientConfig.builder()
.ssl(true)
.build();
// After (recommended)
SslOptions sslOptions = SslOptions.builder()
.build(); // Uses JVM defaults; customise as needed
JedisClientConfig modern = DefaultJedisClientConfig.builder()
.sslOptions(sslOptions)
.build();
The SslOptions API is more explicit and gives you one clear place to manage all TLS configuration. In practice, teams managing multiple Redis connections with different TLS requirements will find it much easier to maintain than scattered ssl(true) flags.
References
FAQ
My app connected fine with ssl(true) before -- why is it failing after upgrading to 7.5?
Hostname verification is now enforced on the legacy TLS path. If your Redis server's certificate SAN or CN does not match the hostname your client is connecting to, Jedis will reject the connection. Check your certificate's SAN entries and make sure they include the exact hostname (or a matching wildcard) you are using.
I use an internal self-signed certificate for Redis -- will Jedis 7.5 break my setup?
Quite possibly, yes. Self-signed certs often lack a proper SAN extension, or their CN does not match the hostname used in the connection string. Fix the cert to include the correct SAN, or switch to SslOptions where you can supply a custom trust store that explicitly trusts that cert.
Does this change affect Jedis Cluster or Sentinel setups?
Yes -- any connection using the legacy ssl(true) path is affected, including those made internally by JedisCluster or JedisSentinelPool if they were initialised with the boolean SSL flag. Each node connection will now go through hostname verification.
Can I temporarily disable hostname verification in 7.5 to avoid breaking changes while I fix my certs?
Yes, using SslOptions you can supply a custom SSLParameters object with hostname verification disabled -- though this should be a short-term workaround, not a permanent config. Move to SslOptions first, then sort out your certificate chain properly.
SSLParameters params = new SSLParameters();
params.setEndpointIdentificationAlgorithm(""); // disables hostname check
SslOptions sslOptions = SslOptions.builder()
.sslParameters(params)
.build();
If I am already using SslOptions, do I need to do anything for this release?
No. The SslOptions-based path is explicitly unchanged in 7.5. If your TLS setup is already going through SslOptions, the new hostname verification behaviour does not apply to you and no changes are required.