n8n Queue Mode SSL Misconfiguration Error

Who this is for: Ops engineers, DevOps, or platform engineers running n8n in Docker, Kubernetes, or on‑premises who need a reliable TLS connection between the n8n queue worker and its broker (Redis, RabbitMQ, etc.). We cover this in detail in the n8n Queue Mode Errors Guide.

---

Quick diagnosis

The queue worker cannot create a TLS‑encrypted channel with the broker and aborts with errors such as:

• TLS handshake failed
• self‑signed certificate
• unsupported protocol

The remedy is a three‑step process:

1. Validate the broker’s certificate chain
2. Align n8n’s TLS settings with the broker
3. Update the runtime environment (Docker, Kubernetes, or bare‑metal) to expose the corrected files

---

Why SSL misconfiguration breaks queue mode?

If you encounter any n8n queue mode docker compose issues resolve them before continuing with the setup.

Symptom (n8n log)	Typical root cause	EEFA note
TLS handshake timeout	Broker forces TLS 1.3 but n8n client only supports ≤ 1.2	Upgrade n8n to v1.10+ (adds TLS 1.3 support)
self‑signed certificate	Missing CA bundle or rejectUnauthorized:true in client config	Never disable verification in production; use a proper CA
certificate verify failed: unable to get local issuer certificate	Incomplete certificate chain (leaf + intermediate only)	Include full chain in the PEM file
unsupported protocol	Broker uses TLS 1.3 only, client compiled with OpenSSL 1.0.2	Re‑build n8n image with OpenSSL 1.1.1+ or downgrade broker to TLS 1.2
ERR_TLS_CERT_ALTNAME_INVALID	Hostname in cert does not match broker address (e.g., using IP)	Use DNS name in QUEUE_HOST or add IP as SAN

EEFA – QUEUE_TLS_REJECT_UNAUTHORIZED=0 disables verification and opens a man‑in‑the‑middle vector. Keep it set to 1 in production.

---

Verify n8n queue TLS settings

If you encounter any n8n queue mode kubernetes deployment errors resolve them before continuing with the setup.

1. List current queue‑related env vars

# Docker / Docker‑Compose
docker exec -it <n8n_container> env | grep ^QUEUE_

# Kubernetes
kubectl exec -it $(kubectl get pod -l app=n8n -o jsonpath="{.items[0].metadata.name}") \
  -- env | grep ^QUEUE_

2. Probe the broker’s TLS version & cipher suite

openssl s_client -connect ${QUEUE_HOST}:${QUEUE_PORT} \
  -servername ${QUEUE_HOST} -tls1_2 </dev/null 2>/dev/null | grep "Cipher"

*If the command fails, the broker is refusing the TLS version you offered.*

3. Confirm the CA bundle is present inside the container

ls -l /certs/ca.pem && \
cat /certs/ca.pem | openssl x509 -noout -text | grep "Subject:"

An empty or missing file triggers verification errors.

---

Correct certificate chain and private key

File	Required content	Common pitfall
queue.crt	PEM‑encoded leaf certificate only	Adding the private key here causes “bad certificate” errors
queue.key	PEM‑encoded private key matching queue.crt	Using a password‑protected key without QUEUE_TLS_PASSPHRASE
ca.pem	Full chain leaf → intermediate(s) → root (concatenated)	Omitting the intermediate leads to “unable to get local issuer”

Assemble the files (example for RabbitMQ)

# leaf certificate
cat /etc/rabbitmq/ssl/cert.pem > /certs/queue.crt

# private key
cat /etc/rabbitmq/ssl/key.pem > /certs/queue.key

# full chain (intermediate + root)
cat /etc/rabbitmq/ssl/ca_certificate.pem \
    /etc/rabbitmq/ssl/intermediate.pem \
    /etc/rabbitmq/ssl/root.pem > /certs/ca.pem

Verify the chain locally

openssl verify -CAfile /certs/ca.pem /certs/queue.crt
# Expected output: /certs/queue.crt: OK

If verification fails, reorder the concatenated files so the leaf appears first, followed by intermediates, then the root.

EEFA – Store private keys in a secret manager (Docker secrets, K8s Secret, HashiCorp Vault). Never commit them to source control.

---

Update environment variables & deployment manifests

Docker‑Compose excerpt

services:
  n8n:
    image: n8nio/n8n:latest
    environment:
      - QUEUE_MODE=redis
      - QUEUE_HOST=redis.example.com
      - QUEUE_PORT=6380
      - QUEUE_TLS=true
      - QUEUE_TLS_REJECT_UNAUTHORIZED=1
      - QUEUE_TLS_CA_FILE=/certs/ca.pem
      - QUEUE_TLS_CERT_FILE=/certs/queue.crt
      - QUEUE_TLS_KEY_FILE=/certs/queue.key
    volumes:
      - ./certs:/certs:ro

Kubernetes deployment snippet

apiVersion: apps/v1
kind: Deployment
metadata:
  name: n8n
spec:
  template:
    spec:
      containers:
        - name: n8n
          image: n8nio/n8n:latest
          env:
            - name: QUEUE_TLS_REJECT_UNAUTHORIZED
              value: "1"
            - name: QUEUE_TLS_CA_FILE
              value: "/certs/ca.pem"
          volumeMounts:
            - name: queue-certs
              mountPath: "/certs"
              readOnly: true
      volumes:
        - name: queue-certs
          secret:
            secretName: n8n-queue-tls

After editing, restart the container or pod so the new files and env vars are loaded.

---

Validate the TLS connection

1. OpenSSL sanity check (run inside the same runtime)

openssl s_client -connect redis.example.com:6380 \
  -CAfile /certs/ca.pem \
  -cert /certs/queue.crt \
  -key /certs/queue.key \
  -tls1_2

*Look for Verify return code: 0 (ok).*

2. n8n health endpoint

curl -s http://localhost:5678/rest/health | jq .queue
# Expected: {"connected":true,"tls":true}

3. Push a test job

n8n execute --workflowId=1 --runData='{}'

Then tail the logs:

docker logs -f <n8n_container> | grep "Queue"

You should see Queue connection established within a few seconds.

EEFA – If the broker requires client‑certificate authentication, also set QUEUE_TLS_CLIENT_CERT_FILE and QUEUE_TLS_CLIENT_KEY_FILE. Missing them yields handshake failure (40) errors.

---

Post‑fix monitoring & EEFA checklist

Checklist item	How to verify
TLS version match – both broker and n8n support ≥ TLS 1.2	openssl s_client -connect … -tls1_2 succeeds
Full chain present – ca.pem includes all intermediates	openssl verify -CAfile ca.pem queue.crt → OK
Private key unencrypted or passphrase supplied via QUEUE_TLS_PASSPHRASE	openssl rsa -in queue.key -check (no prompt)
Env vars reflect TLS – QUEUE_TLS=true and QUEUE_TLS_REJECT_UNAUTHORIZED=1	docker exec … env | grep QUEUE_TLS
No runtime warnings – logs show Queue connection established quickly	docker logs -f n8n | grep "Queue"
Secret management – certs stored in Docker secret / K8s Secret, not in the image	docker inspect … → Mounts show secret source

Monitoring tip

Enable n8n metrics (METRICS=true) and scrape /metrics with Prometheus. Watch n8n_queue_connection_errors_total for any spikes after deployment.

---

Conclusion

A correctly configured TLS chain and matching n8n settings are essential for reliable queue‑mode operation. By verifying the broker’s advertised TLS version, ensuring a complete ca.pem chain, and exposing the certificates via secure secrets, you eliminate handshake failures and protect production traffic. Follow the EEFA checklist, monitor the built‑in metrics, and keep your secrets out of source code to maintain a robust, production‑grade n8n deployment.