Redis TLS certificate expired

x509: certificate has expired from Go redis clients or SSL_connect failed in redis-cli means redis-server presented an old leaf—not that your ACL password rotated.

SREs debugging redis tls certificate expired notice workers, Sidekiq, Celery, or BullMQ stalling when caches and brokers enforce TLS on 6379/6380. Unlike HTTPS, there is often no browser padlock—only cryptic handshake errors buried in worker logs.

Redis TLS is configured via tls-port, tls-cert-file, tls-key-file, tls-ca-cert-file, and optional client cert requirements. Elasticache and Memorystore manage server identities; self-hosted Redis on Kubernetes mounts PEMs from Secrets that may drift from what sidecars present.

Dragonfly and Valkey-compatible deployments follow similar TLS configuration patterns—if you migrated engines recently, confirm whether automation still watches the pre-migration Service DNS name. Pub/sub fan-out magnifies TLS errors: one expired cert means thousands of subscribers log errors within the same second, which monitoring tools may classify as a DDoS unless deduplicated.

Frame customer impact in terms of failed checkouts, delayed notifications, or stalled background jobs—the business symptom helps prioritize renewal over exploratory Redis tuning that cannot fix PKIX dates. Always capture the broker URL from the failing worker log line.

First response

Collect the failing client stack trace, Redis URL scheme (rediss://), and whether TLS terminates on a service mesh. Capture redis-cli --tls output if available. From a network vantage matching production, handshake to the service DNS name on the TLS port.

Document if stunnel, Envoy, or AWS NLB front Redis—the certificate clients see may not live on the Redis pod. Save serial numbers before renewal. Cross-link queue symptoms with curl SSL expired when HTTP health checks still pass while async pipelines die.

If you use Redis ACLs, capture ACL LIST and the exact username in the failing URL—TLS failures happen before AUTH errors, but tickets often blame passwords first. For cluster mode, run redis-cli --tls -c CLUSTER NODES only after strict PING works on the seed node; partial cluster views during cert incidents waste time chasing phantom slot errors.

What this error means

Redis speaks a minimal TLS handshake when tls-port is enabled (or when port 0 with TLS-only mode). Clients validating trust reject expired server certificates immediately. rediss:// URLs in Heroku-style platforms often imply server verification against public CAs—internal CAs need custom CA bundles in clients.

Client certificates (tls-auth-clients yes) expire separately. Expired server certs break all TLS clients; expired client certs break only identities bound to those certs. Replication over TLS (tls-replication yes) fails symmetrically when any node serves stale material.

Redisson, ioredis, and Sidekiq 7+ default toward TLS in many Helm charts—legacy cron jobs on the same cluster may still use plaintext on 6379, hiding expiry until a security hardening flag flips globally. Rate limiting and throttle middleware that shares Redis clusters inherits the same TLS identity as sessions.

TLS session resumption caches can keep old sessions alive briefly after server renewal—still fix the cert, but expect transient mixed behavior until clients reconnect. Autoscaling may replace pods that served good TLS while others still present expired mounts if StatefulSet ordering is wrong during secret updates.

Managed queues that share Redis with real-time features need joint comms during TLS rotation—marketing push campaigns may spike reconnect load alongside checkout traffic. Record whether TLS terminates on the broker or a mesh sidecar in the ticket header for faster routing.

Common causes

Kubernetes Secret rotation without rolling Redis pods leaves old mounts. cert-manager issued a cert for redis.default.svc.cluster.local while apps connect via redis.prod.example.com through an NLB with a different expired default cert.

Operator renewed PEMs on disk but skipped CONFIG REWRITE / reload semantics documented for your distribution. Mixed TLS and plaintext ports caused monitors to hit plaintext while apps used rediss://. Sentinel or Cluster bus ports reuse TLS settings inconsistently across shards.

AWS Memorystore and ElastiCache enforce TLS with downloadable CA bundles—expiry manifests as cluster-wide timeouts when the Amazon-managed identity rotates and clients pin old ca.pem. KeyDB and Redis Enterprise expose per-database TLS settings; one expired leaf on a shard breaks only the keyspace mapped to that node unless clients use cluster-aware routing. Istio mTLS sidecars can double-encrypt traffic; openssl to the Kubernetes Service may show the sidecar cert while the Redis pod cert is separate—test both hops.

Confirm from the outside

Use the same password, ACL, and TLS flags production clients use—redis-cli PING without TLS when the app uses rediss:// wastes triage time. Test sentinel and cluster bootstrap nodes individually when DNS round-robins across shards. Capture which Kubernetes namespace and Secret version mounted during failures so platform engineers can diff after renewal.

openssl s_client -connect redis.example.com:6380 </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

redis-cli -h redis.example.com -p 6380 --tls --cacert /path/ca.pem --insecure -e PING

Remove --insecure when reproducing production verification:

redis-cli -h redis.example.com -p 6380 --tls --cacert /path/ca.pem PING

Inspect server configuration (if you have CLI access):

redis-cli CONFIG GET tls-cert-file
redis-cli CONFIG GET tls-key-file

Sidekiq, Resque, Bull, and Celery logs often truncate TLS errors—enable verbose broker logging once to capture the hostname in the failing rediss:// URL. Go-redis and Lettuce surface x509: certificate has expired with the peer name—paste that into your ticket subject line for faster routing to platform owners.

How to read the output

Expired notAfter is definitive for verifying clients. Confirm SAN covers the hostname in rediss:// URLs, not only the internal service name. Issuer switches after moving from self-signed to public CA require distributing new ca.pem to every client library.

Fix checklist

1. List every Redis endpoint: primary, replicas, sentinel, cluster nodes, and mesh ingress.
2. OpenSSL each TLS port from an app subnet.
3. Renew server leaf (and client certs if used for mTLS).
4. Update Secret mounts or tls-*-file paths with correct permissions (640 key, owned by redis).
5. Rolling restart Redis pods or SHUTDOWN SAVE in a controlled window per shard.
6. Redeploy workers with updated ca.pem if CA rotation occurred.
7. Re-run failing job enqueue/consume tests.
8. Monitor TLS port directly, not only HTTP probes.

During rollout, watch replication offset and sentinel quorum so you do not declare victory while a minority shard still serves expired TLS on read replicas. Warm connection pools in API pods may need graceful restart after server renewal because long-lived connections negotiated before reload can appear healthy until they reconnect.

Notify fraud and payments teams when rate-limiting Redis clusters renew TLS—brief API latency during mass reconnects has triggered false chargeback spikes in some ecommerce estates. Document sentinel announce IPs separately from application Redis URLs if your chart exposes both.

Label Secrets with notAfter annotations in GitOps repos when your CD tool supports it—reviewers spot stale dates before merge. Restart one canary worker pod and confirm job dequeue before full fleet rollout. Log the renewed serial in the change record.

When to use automation

Queue depth alerts lag handshake failures. Run scheduled live TLS checks on Redis hostnames and TLS ports your rediss:// URLs use. Try /check when the name resolves publicly; private clusters need VPC synthetics.

Alert at 30, 14, 7, and 1 days before notAfter, and track RDAP on domains used in DNS validation for public certs fronting Redis. Email works on free tiers; Slack and Discord webhooks need Starter or Pro.

Queue metrics spike minutes after handshake failures—correlate Grafana blocked clients with /check results on broker URLs. Cross-link monitoring with PostgreSQL SSL certificate expired when the same platform team owns both data stores on one Terraform module.

Treat session persistence in Phoenix channels and ActionCable-style adapters as consumers of the same Redis TLS identity; they fail identically when rediss:// verification is on.

Operator runbooks for Redis Enterprise should include rladmin certificate update steps distinct from open-source redis.conf edits—mixing instructions causes double maintenance windows. Game backends using Redis pub/sub for matchmaking feel player-facing impact within seconds; prioritize handshake probes on those clusters.

Disaster recovery failovers to secondary regions sometimes mount stale secrets if DR secrets management lagged primary—validate TLS on the DR URL during quarterly drills, not only TCP connectivity. Document rediss:// URL fragments in Terraform outputs so security reviews audit the same names monitoring watches.

Post-fix validation should drain one worker pod at a time and watch queue depth recover—if depth rises while TLS succeeds, you may have uncorked a separate backlog. Record cert serial in Helm values.yaml comments or External Secrets annotations so the next engineer sees rotation history without digging through chat logs.

Capacity planning notes should mention TLS handshake CPU cost after large-scale reconnects—temporary latency spikes after renewal are normal while every client renegotiates. Document maximum connection counts per broker so you do not mistake renewal thundering herds for memory leaks.

Platform SREs should export every rediss:// hostname from Kubernetes Secrets in a nightly report and diff against the monitoring inventory—Shadow brokers from forgotten namespaces are a common miss. Starter plans monitor twenty-five names hourly; Pro expands to one hundred when each environment duplicates broker endpoints.