Redis TLS (rediss://) handshake failure in CI

By Daniel Zoghalchali·Latchkey

A TLS mismatch: either the client spoke plaintext to a TLS-only Redis (openssl reports "wrong version number"), or it spoke TLS but could not verify the certificate. The rediss:// scheme enables TLS on the client side and must match how the server is configured.

What this error means

Connecting fails with an SSL error such as "wrong version number", "SSL routines", or a certificate verification failure when the Redis service is TLS-enabled.

Error: 140... error:1408F10B:SSL routines:ssl3_get_record:wrong version number
# or on the client:
Error: connect ... SSL alert number 46 (certificate verify failed)

Common causes

Plaintext client against a TLS port

"wrong version number" means the client sent an unencrypted RESP handshake to a TLS listener; you must use rediss:// (or redis-cli --tls).

Untrusted or self-signed server certificate

A TLS handshake that reaches certificate validation fails when the CI trust store does not include the CA that signed the Redis certificate.

How to fix it

Use TLS on the client to match the server

1. Switch the URL scheme to rediss:// (or pass --tls to redis-cli).
2. Provide the CA file if the certificate is self-signed.
3. Verify with an authenticated PING over TLS.

redis-cli --tls --cacert ca.pem -h localhost -p 6379 ping

Configure the client TLS in code

For ioredis, enable TLS and point at the CA so verification succeeds.

import fs from 'node:fs';
import Redis from 'ioredis';
const client = new Redis({
  host: 'localhost', port: 6379,
  tls: { ca: fs.readFileSync('ca.pem') },
});

How to prevent it

• Match client scheme to server: rediss:// for a TLS listener.
• Ship the CA into CI when the certificate is self-signed.
• Do not disable certificate verification as a permanent fix.

Frequently asked questions

Related guides

References

• GitHub Actions documentation