[Bug]: Redis Cloud autodiscovery imports databases without TLS → `read ECONNRESET`

[marcinkubica]

Redis Cloud autodiscovery imports databases without TLS → read ECONNRESET

Component: API backend — Cloud autodiscovery (redisinsight/api/src/modules/cloud/autodiscovery)
Affected RedisInsight: Desktop 3.4.2 (Electron), reproduced on macOS

---

Summary

RedisInsight's "Add Redis Cloud database" (Cloud autodiscovery) flow creates the imported
database connection without TLS. When the discovered Redis Cloud database requires TLS in
transit (the secure, and for some of us compliance-mandated, configuration), the resulting
plaintext connection is reset by the server and the import fails with:

Could not connect to <host>:<port>, please check the connection details.
cause: read ECONNRESET

Connect with: both Redis Cloud account and Redis Cloud API keys

---

Environment / what was verified independently

• Redis Cloud Pro subscription; database with TLS enabled (transit encryption), a public
  endpoint, a source-IP allow-list, and default-user AUTH.
• From the same machine that RedisInsight runs on:
  • openssl s_client -connect <public-endpoint> → TLSv1.3 handshake OK, Verify return code: 0 (ok) (publicly-trusted GlobalSign cert; SAN covers the public hostname).
  • redis-cli -h <host> -p <port> --tls --user default --pass <pw> PING → PONG.
  • Raw nc to the port → connected (source IP is allow-listed).

So: endpoint reachable ✔, firewall/allow-list ✔, TLS ✔, AUTH ✔. The only failing path is RedisInsight's
autodiscovery import.

---

Symptom (backend log, launched with RI_LOG_LEVEL=debug RI_STDOUT_LOGGER=true)

[CloudAutodiscoveryService] Adding Redis Cloud databases.
[CloudDatabaseCapiService] Getting cloud database - { subscriptionId: …, databaseId: …, free: false }
[IoredisRedisConnectionStrategy] Creating ioredis standalone client
[IoredisRedisConnectionStrategy] ERROR Failed connection to the redis database. - error: { message: 'read ECONNRESET' }
[DatabaseService]            ERROR Failed to add database. -
  RedisConnectionUnavailableException: Could not connect to <host>:<port>, please check the connection details.
  cause: { message: 'read ECONNRESET' }

read ECONNRESET during connect is the textbook signature of a plaintext client hitting a
TLS-only server — the server accepts the TCP socket then resets it when it receives a
non-TLS RESP handshake.

---

Root cause

redisinsight/api/src/modules/cloud/autodiscovery/cloud-autodiscovery.service.ts →
addRedisCloudDatabases():

const [host, port] = publicEndpoint.split(':');

await this.databaseService.create(sessionMetadata, {
  host,
  port: parseInt(port, 10),
  name,
  nameFromProvider: name,
  password,
  provider: HostingProvider.REDIS_CLOUD,
  cloudDetails: database?.cloudDetails,
  tags,
  timeout: cloudConfig.cloudDatabaseConnectionTimeout,
});
// ↑ no `tls`, no `caCert`, no `verifyServerCert`, no `tlsServername`

Three facts confirm the connection ends up plaintext:

1. The create() payload never sets tls (above).
2. Database.tls is optional with no default — redisinsight/api/src/modules/database/models/database.ts:

   tls?: boolean;          // 'Use TLS to connect.'  → undefined ⇒ plaintext

3. No provider/cloud-based TLS default anywhere in the database create path (e.g. nothing keys
   tls = true off HostingProvider.REDIS_CLOUD or cloudDetails).

⇒ Every database imported via Cloud autodiscovery is created without TLS.

Compounding gap: the CAPI model has no transit-TLS field

Even if addRedisCloudDatabases wanted to derive TLS from the discovered database, it can't:
redisinsight/api/src/modules/cloud/database/models/capi.interface.ts:

interface ICloudCapiDatabaseSecurity {
  password?: string;
  sslClientAuthentication: boolean;   // mTLS client-cert auth — NOT transit TLS
  sourceIps: string[];
}

and the converter redisinsight/api/src/modules/cloud/database/utils/cloud-data-converter.ts only
maps password and sslClientAuthentication. There is no "TLS in transit / enabled" flag
modelled at all — only client-certificate auth, which is a different thing. So the importer has no
transit-TLS signal and doesn't set TLS regardless.

---

Impact

Any TLS-enabled Redis Cloud database — which is the secure default and is mandatory for
regulated deployments (e.g. MiCA, encryption-in-transit) — cannot be added through Cloud
autodiscovery. It always fails with read ECONNRESET. Only databases with TLS disabled can be
imported this way, which pushes users toward the less-secure option or a confusing manual fallback.

---

Proposed fix

Option A (minimal): in addRedisCloudDatabases, set tls: true for
HostingProvider.REDIS_CLOUD imports. Redis Cloud Pro/Flexible endpoints terminate TLS and present
a publicly-trusted certificate on the public hostname, so default server-cert verification succeeds
(verifyServerCert: true is safe; no CA upload needed). This makes autodiscovery match what a
correct manual connection does.

Option B (robust): thread a real transit-TLS flag from the CAPI database object through
ICloudCapiDatabaseSecurity → parseCloudDatabaseCapiResponse (cloud-data-converter.ts) →
CloudDatabase, and set tls from it in addRedisCloudDatabases (still defaulting to true for
Redis Cloud if the field is absent). Requires confirming the CAPI response carries such a field.

Either way addRedisCloudDatabases must stop creating Redis Cloud connections with tls unset.

---

Workaround (for users, until fixed)

Add the database manually instead of via autodiscovery:

• Add Database → "Connect to a Redis Database" (manual) → expand connection settings:
  • Host / Port = the database's public (or private) endpoint
  • Username default, Password = the database's default-user password
  • ☑ Use TLS (leave "Requires TLS Client Authentication" unchecked)
• Delete the failed autodiscovered entry.

---

Code references

File	What
redisinsight/api/src/modules/cloud/autodiscovery/cloud-autodiscovery.service.ts	addRedisCloudDatabases() — databaseService.create({...}) omits tls
redisinsight/api/src/modules/cloud/database/utils/cloud-data-converter.ts	parseCloudDatabaseCapiResponse() — maps only password + sslClientAuthentication
redisinsight/api/src/modules/cloud/database/models/capi.interface.ts	ICloudCapiDatabaseSecurity — no transit-TLS field
redisinsight/api/src/modules/database/models/database.ts	tls?: boolean — optional, no default

---

Appendix A — log evidence

Backend started with verbose logging:

RI_LOG_LEVEL=debug RI_STDOUT_LOGGER=true "/Applications/Redis Insight.app/Contents/MacOS/Redis Insight"

Live endpoint host, subscription/database IDs and the connection password are redacted as
<PUBLIC_ENDPOINT>, <PORT>, <SUB_ID>, <DB_ID>, <RI_UUID>, ***.

A.1 — Autodiscovery path is used, then the ioredis client fails with read ECONNRESET

[CloudAutodiscoveryService] Discovering cloud databases from subscription(s)
[CloudAutodiscoveryService] Adding Redis Cloud databases.
[CloudDatabaseCapiService] Getting cloud database - {
  data: [ { subscriptionId: <SUB_ID>, subscriptionType: 'flexible', databaseId: <DB_ID>, free: false } ]
}
[CloudDatabaseCapiService] Succeed to get databases in RE cloud subscription.
[DatabaseService] Creating new database.
[IoredisRedisConnectionStrategy] Creating ioredis standalone client - {
  data: [ { databaseId: '<RI_UUID>', context: 'Common' } ]
}
[IoredisRedisConnectionStrategy] ERROR Failed connection to the redis database. - {
  error: { type: 'Error', message: 'read ECONNRESET' },
  data: [ { databaseId: '<RI_UUID>', context: 'Common' } ]
}
[DatabaseService] ERROR Failed to add database. - {
  error: {
    type: 'RedisConnectionUnavailableException',
    message: 'Could not connect to <PUBLIC_ENDPOINT>:<PORT>, please check the connection details.',
    cause: { type: 'Error', message: 'read ECONNRESET' }
  }
}
[CloudAutodiscoveryService] ERROR Adding cloud database failed with an error - {
  error: {
    type: 'RedisConnectionUnavailableException',
    message: 'Could not connect to <PUBLIC_ENDPOINT>:<PORT>, please check the connection details.',
    cause: { type: 'Error', message: 'read ECONNRESET' }
  }
}

A.2 — Retries fail the same way; server resets every attempt

[IoredisRedisConnectionStrategy] Reconnecting to the redis database
[IoredisRedisConnectionStrategy] ERROR Failed connection to the redis database. - { error: { message: 'read ECONNRESET' } }
[IoredisRedisConnectionStrategy] ERROR Failed connection to the redis database. - {
  error: { type: 'MaxRetriesPerRequestError',
           message: 'Reached the max retries per request limit (which is 1). Refer to "maxRetriesPerRequest" option for details.' }
}
[IoredisRedisConnectionStrategy] WARN Server closed the connection.

read ECONNRESET on connect (the server resets the socket) is what a TLS-only Redis endpoint
does when the client speaks plaintext RESP — consistent with the imported connection having
tls unset (see Root cause).

A.3 — Positive control: the same endpoint works over TLS (so server/endpoint/creds are fine)

# TLS handshake succeeds against the identical public endpoint:
$ openssl s_client -connect <PUBLIC_ENDPOINT>:<PORT> -servername <PUBLIC_ENDPOINT>
CONNECTED(00000005)
subject=C=US, ST=California, L=San Francisco, O=Redis, CN=<...>.db.redis.io
issuer=C=BE, O=GlobalSign nv-sa, CN=GlobalSign Atlas R3 OV TLS CA 2026 Q2
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Verify return code: 0 (ok)

# Authenticated PING over TLS succeeds:
$ redis-cli -h <PUBLIC_ENDPOINT> -p <PORT> --tls --user default --pass '***' PING
PONG

A.3 succeeding while A.1 fails isolates the defect to the autodiscovery-created connection
(plaintext), not the network, endpoint, certificate, allow-list, or credentials.

Note: the same run also logged unrelated Chromium-stack errors
ssl_client_socket_impl.cc … handshake failed … net_error -202 (ERR_CERT_AUTHORITY_INVALID)
for RedisInsight's own outbound HTTPS (cloud API / telemetry). Those are a separate matter
(a TLS-intercepting corporate VPN presenting an untrusted CA to the Electron/Chromium net stack)
and are not the database-connection failure — the DB path uses ioredis, whose error is the
read ECONNRESET above.

[valkirilov]

Thanks for reproing this @marcinkubica, we'll take a look 👍

[marcinkubica]

@valkirilov thanks! Also seems there's no test coverage for this TLS part thing.
Tried 3.2.0, 3.0.0 - same