Verify TLS support against a real TLS server

[jamesx-improving]

---

Context

TLS is already implemented end-to-end — this is not a request to add TLS support. The path is wired:

• Orchestrator (scripts/run_benchmark_matrix.py): cli_connection_args builds --tls/--cacert/--cert/--key/--insecure, used by both preflight PING and per-cell FLUSHALL.
• Schema (configs/schemas/driver-config.schema.json): a tls object (enabled, cert_path, key_path, ca_path, verify_hostname).
• Engines: Jedis, StackExchange.Redis (C#), and valkey-glide (Ruby) configure the client from that config.

The gap is verification, not capability: the TLS path has only ever been unit-tested (flag construction in isolation). No local TLS endpoint, certs, or test target exists, so the flags and the engine-side TLS wiring have never run against a real TLS server. Disclosed under "Not verified / known limitations" in #6.

Evidence the untested path is already broken: the Ruby valkey-glide client reads ca_cert_path and verify_peer (ruby/lib/resp_bench/client/impl/valkey_glide_client.rb:95,98), while the schema and orchestrator use ca_path and verify_hostname. A schema-valid TLS config silently drops the CA path and misreads peer verification for that engine. Unit tests can't catch it because nothing flows a real config through both sides.

Existing test infrastructure (why this is one issue, not two)

Per-engine integration suites (java/.../integration, csharp/.../Integration, ruby/test/integration) already connect to a real server at localhost:6379 via VALKEY_HOST/VALKEY_PORT, skipping when unavailable. TLS cases can extend these — no new test framework needed. What's missing is a way to provision a TLS server + certs (no docker-compose, Dockerfile, or Makefile TLS server/cert target exists). The Python e2e pipeline test is serverless (recording client) and is out of scope.

Note: there is no test-running CI in this repo, so this coverage will run locally; automating it in CI is out of scope here.

Scope

1. Provision certs + TLS server for tests. Repeatable local cert generation (CA, server, client) + a TLS-enabled Valkey/Redis server (e.g. make tls-test-server and/or docker-compose service). Document how to run it.
2. Orchestrator coverage. Exercise preflight_server (PING) and flush_server (FLUSHALL) against the TLS endpoint with --tls/--cacert/--cert/--key, plus the --insecure (verify_hostname=false) path.
3. Engine coverage. Add TLS integration cases to the existing per-engine suites, driving each client through a schema-valid tls config against the TLS server. This surfaces the Ruby key mismatch.
4. Fix the Ruby key mismatch.
5. Optional: mutual-TLS variant (flags/config already carry client cert_path/key_path).

Out of scope

• Adding TLS support (already implemented).
• The serverless Python e2e pipeline test.

Related

• Follows up on Matrix runner: fail loudly, isolate runs, report status honestly #6 (disclosed limitation).