RabbitMQ SSL certificate expired

rabbitmq ssl certificate expired stops AMQPS publishers and consumers when the broker’s TLS listener still serves a leaf past notAfter on 5671.

Queue depth climbs while applications log SSLHandshakeException, certificate verify failed, or connection reset. Plain AMQP on 5672 may still work, tempting teams to downgrade encryption—fix the cert instead.

RabbitMQ clusters fronted by TCP load balancers can terminate TLS twice. openssl must target the hostname and port your client libraries actually use.

First response

Document vhost, user, client library (pika, amqp.net, Spring AMQP), and connection URI using amqps scheme. Capture rabbitmq-diagnostics status or management UI listener table, openssl against HOST:5671, and whether TLS terminates on HAProxy before RabbitMQ.

Include cluster node name if only one member in a mirrored policy serves stale PEM files from local disk.

Brokers share patterns with WebSocket SSL certificate expired when realtime apps use both wss and amqps behind the same edge.

What this error means

When ssl_options or modern listeners.ssl config enables TLS, the broker presents certfile during handshake before AMQP starts. Clients verify notAfter like any HTTPS stack.

Expired server certificates close TCP during handshake. Management UI on 15671 may share the same cert—operators notice both API and UI SSL failures together.

Client certificate authentication is separate; this guide focuses on server expiry blocking most connections.

Common causes

PEM renewed in Chef/Ansible but not deployed. Config management wrote new files while rabbitmq-server was not restarted.

Rolling cluster with local cert paths. Each node mounts different fullchain.pem ages behind the same DNS name.

Load balancer still binds old cert. Clients openssl to the VIP while nodes appear healthy on management checks.

Merged PEM missing intermediates. RabbitMQ serves leaf only; some clients fail earlier, but expiry on the leaf still breaks everyone simultaneously.

Let’s Encrypt ninety-day cadence missed. Automation renewed disk certs but hook did not reload rabbitmq-server.

Shovels still use old amqps URL. Federation errors look like app bugs while local broker cert is fine.

Confirm from the outside

OpenSSL on AMQPS

HOST=mq.example.com
echo | openssl s_client -connect "${HOST}:5671" -servername "${HOST}" 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

listener check

sudo rabbitmq-diagnostics listeners

Python amqps probe

python -c "import ssl,socket; ctx=ssl.create_default_context(); s=socket.create_connection(('HOST',5671),10); ss=ctx.wrap_socket(s,server_hostname='HOST'); print(ss.version(), ss.getpeercert()['notAfter'])"

How to read the output

Past notAfter on the leaf from openssl explains broker-wide handshake failures. Match SANs to the hostname in amqps URIs. Compare cert files on each cluster node when VIP health checks pass but clients still fail intermittently.

Fix checklist

1. Confirm expiry on 5671 and 15671 if used.
2. Obtain replacement with correct SANs for client-visible DNS.
3. Install certfile, keyfile, and cacertfile per RabbitMQ docs.
4. Sync config across cluster members; restart rabbitmq-server on each node in a controlled window.
5. Update load balancer passthrough cert if TLS stops at the LB.
6. Reconnect publishers with verify_peer enabled—no ssl_options bypass.
7. Drain queues and confirm consumer recovery metrics.
8. Monitor live TLS on the AMQPS endpoint.

Publish openssl serial after restart before declaring all-clear—management UI green does not replace client handshake proof.

rabbitmq ssl certificate expired rollouts should restart nodes in a defined order when mirrored queues depend on stable leaders—document which vhost drained first. If TLS terminates on HAProxy, renew there and on brokers when passthrough is used; openssl to the VIP is the customer view. After fix, replay a publisher burst test with verify_peer enabled to confirm consumers catch up.

Triage myths: disabling verify in client libraries does not renew server notAfter. Bumping Erlang or RabbitMQ patch levels without PEM rotation leaves TLS broken. When only one microservice fails, openssl its amqps URL anyway—shared brokers often serve many teams with one expired edge cert.

Measurement gaps: queue depth alerts without TLS checks greenlight traffic into brokers that clients cannot reach. Add synthetic amqps handshakes beside depth metrics so the next rabbitmq ssl certificate expired page fires before messages pile up for hours.

Broker owners should label which connection strings use amqps in internal docs—on-call often openssl the wrong VIP when management UI TLS and AMQPS diverge. After incidents, review whether federation shovels shared the same expired edge cert; fixing the local node does not heal cross-datacenter links still pinned to old material.

Spring AMQP and MassTransit configs often hardcode amqps hosts in multiple repos—grep during post-mortems so one missed values file does not reopen rabbitmq ssl certificate expired a week later.

Operators managing quorum queues should verify TLS on every node before declaring success—partial reloads leave one quorum member presenting yesterday's fullchain while others already renewed.

Archive management plugin screenshots showing listener dates only as supplemental evidence—openssl serial on 5671 remains the acceptance test.

When to use automation

Message buses are internal but still TLS-terminated. Probe 5671 with openssl synthetics or dedicated monitors, not only public HTTPS. /check covers 443-style hosts; AMQPS needs the same notAfter discipline on messaging DNS.

Alert at 30, 14, 7, and 1 days; pair with RDAP on broker DNS when ownership changes block reissue.