🚨 RabbitMQ Error Guide: 'certificate verify failed' TLS Trust and mTLS Verification Errors

Exact Error Message

A certificate verification failure means the TLS handshake negotiated a session successfully, but one side rejected the other’s certificate. The cipher and protocol were agreed; trust was not. This happens on port 5671 and shows up as a tls_alert referencing the certificate.

2026-06-29 16:22:48.713 [error] <0.24410.9> TLS server generated SERVER ALERT: Fatal - Unknown CA -
{bad_cert,unknown_ca}
2026-06-29 16:22:48.713 [error] <0.24410.9> Error on AMQP connection <0.24410.9> (10.0.6.42:53880 -> 10.0.4.21:5671, state: starting):
{ssl_upgrade_error,{tls_alert,{unknown_ca,"received CLIENT ALERT: Fatal - Unknown CA"}}}
2026-06-29 16:25:10.004 [error] <0.24455.9> TLS server: ... {bad_cert,cert_expired}
2026-06-29 16:31:55.220 [error] <0.24512.9> TLS server: ... {fail_if_no_peer_cert,no_peer_certificate}

A client validating the broker’s certificate typically reports:

ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch

What the Error Means

After TLS negotiation, each side may present a certificate and the peer validates it against a trusted CA, checks validity dates, and (for the broker’s cert) checks the hostname. Verification fails when any of these checks fails:

• unknown_ca — the presented cert was not signed by a CA the verifier trusts.
• cert_expired (or certificate_expired) — the cert is outside its notBefore/notAfter window.
• no_peer_certificate — with fail_if_no_peer_cert = true (mutual TLS), the client presented no client certificate.
• Hostname mismatch — the broker cert’s CN/SAN does not match the hostname the client connected to.

This is distinct from a handshake/negotiation failure: here the encrypted channel was establishable, but the identity proof was rejected. Trust direction matters — the broker verifies client certs (mTLS), and the client verifies the broker cert.

Common Causes

1. Client does not trust the broker’s CA

The client’s CA bundle does not include the CA (often an internal/private CA) that signed the broker certificate. Result: unable to get local issuer certificate / unknown_ca.

2. Broker does not trust the client’s CA (mTLS)

With verify_peer enabled, the broker’s cacertfile does not chain to the client cert’s issuer, so the broker sends Unknown CA.

3. Expired (or not-yet-valid) certificate

A cert past its notAfter date — a classic forgotten-rotation outage — fails with cert_expired. Clock skew can also trigger not-yet-valid errors.

4. Missing client certificate under fail_if_no_peer_cert

The broker requires a client cert (fail_if_no_peer_cert = true) but the client connects without one, producing no_peer_certificate.

5. Hostname / SAN mismatch

The client connects to a name not present in the broker cert’s Subject Alternative Names. Modern clients reject this even when the chain is valid.

6. Incomplete chain presented

The broker presents a leaf cert without its intermediate(s), so clients without the intermediate cannot build a path to the root.

How to Reproduce the Error

Trigger an unknown-CA and a hostname-mismatch verification failure with openssl:

# Verify the broker cert against a CA bundle that does NOT include its issuer
openssl s_client -connect 10.0.4.21:5671 -CAfile /etc/ssl/certs/ca-bundle.crt </dev/null 2>&1 | \
  grep -E 'verify (error|return code)'

# Connect by IP/wrong name to force a hostname (SAN) mismatch
openssl s_client -connect 10.0.4.21:5671 -verify_hostname wrong.example.com </dev/null 2>&1 | \
  grep -iE 'verify|hostname'

# mTLS: connect without a client cert to a broker requiring one
openssl s_client -connect 10.0.4.21:5671 </dev/null 2>&1 | grep -iE 'alert|peer'

A non-matching -CAfile yields verify error:num=20:unable to get local issuer certificate; the wrong name yields a hostname-verification error.

Diagnostic Commands

# Show the full chain the broker presents and the verify result
openssl s_client -connect 10.0.4.21:5671 -servername mq.internal -showcerts </dev/null 2>&1 | \
  grep -E 'verify return code|s:|i:|subject|issuer'

# Inspect the broker certificate's dates, subject, and SANs
openssl x509 -in /etc/rabbitmq/certs/server_certificate.pem -noout -dates -subject -issuer -ext subjectAltName

# Validate the broker cert chains to a given CA file
openssl verify -CAfile /etc/rabbitmq/certs/ca_certificate.pem /etc/rabbitmq/certs/server_certificate.pem

# Check whether the broker requires/verifies client certs (mTLS)
rabbitmqctl environment | grep -A12 'ssl_options'
rabbitmq-diagnostics listeners

# Watch verification alerts as connections fail
sudo journalctl -u rabbitmq-server -f | grep -E 'bad_cert|unknown_ca|cert_expired|no_peer_certificate|ALERT'

Step-by-Step Resolution

Step 1: Identify the specific verification failure

Read the alert reason: unknown_ca, cert_expired, no_peer_certificate, or hostname mismatch. Each has a different fix, so do not guess.

Step 2: For unknown_ca, fix the trust store on the verifying side

If the client fails to trust the broker, add the broker’s CA to the client’s CA file (cacertfile / ca-bundle). If the broker rejects the client cert, add the client’s issuing CA to the broker’s ssl_options.cacertfile.

Step 3: For expired certs, check dates and rotate

openssl x509 -in /etc/rabbitmq/certs/server_certificate.pem -noout -dates

If past notAfter, reissue and deploy the new cert, then restart/reload the listener. Verify NTP if “not yet valid” appears (clock skew).

Step 4: For no_peer_certificate, supply a client cert

If mTLS is intended (fail_if_no_peer_cert = true), configure the client with certfile/keyfile. If mTLS is not intended, set fail_if_no_peer_cert = false and verify = verify_none (or verify_peer without requiring a cert) per your policy.

Step 5: For hostname mismatch, fix SAN or the connect name

Confirm the connect hostname is in the cert SANs:

openssl x509 -in /etc/rabbitmq/certs/server_certificate.pem -noout -ext subjectAltName

Either connect using a name in the SAN list, or reissue the cert with the correct SAN. Do not disable hostname verification in production.

Step 6: Ensure the full chain is presented

Concatenate intermediates with the leaf in the broker’s certfile so clients can build a complete path to the root.

Prevention and Best Practices

• Distribute your internal CA to every client and broker trust store as part of provisioning, so private-CA certs verify everywhere.
• Monitor certificate expiry and automate rotation well before notAfter; expired broker certs are a recurring, fully avoidable outage.
• Always include every hostname/VIP a client may use in the broker cert’s SANs, and keep hostname verification enabled.
• Decide mTLS policy deliberately: if fail_if_no_peer_cert = true, ensure every client ships a valid client cert and its CA is trusted by the broker.
• Bundle intermediates with leaf certs so clients never fail on an incomplete chain.
• For fast triage, the free incident assistant can map a bad_cert reason to the exact trust fix.

Related Errors

• TLS handshake failed / no_suitable_ciphers — negotiation failure before any cert is validated (separate guide).
• Socket closed abruptly during SSL handshake — a peer dropping mid-handshake rather than sending a cert alert.
• ACCESS_REFUSED - Login was refused — AMQP-level auth, which happens after TLS succeeds; a cert failure never reaches it.
• ECONNREFUSED on 5671 — no TLS listener, distinct from a cert being rejected.

More in the RabbitMQ guides.

Frequently Asked Questions

What is the difference between this and a TLS handshake failure? A handshake/negotiation failure means the two ends could not agree on a protocol or cipher — no secure channel formed. A certificate verify failure means the channel formed but the peer’s identity was rejected (unknown CA, expired, wrong hostname, or missing client cert).

Why does my client say “unable to get local issuer certificate”? The client cannot build a chain from the broker’s certificate to a CA it trusts. Add the broker’s signing CA (and any intermediates) to the client’s CA bundle, or fix the broker to present the full chain.

What does fail_if_no_peer_cert do? With fail_if_no_peer_cert = true, the broker rejects any TLS client that does not present a certificate, enforcing mutual TLS. Clients must be configured with certfile/keyfile whose issuer the broker trusts, or the handshake fails with no_peer_certificate.

My chain is valid but I still get “Hostname mismatch” — why? The certificate is trusted and unexpired, but the name you connected to is not listed in its Subject Alternative Names. Connect using a name in the SANs, or reissue the certificate with the correct SAN. Avoid disabling hostname verification.

How do I check a certificate’s expiry and SANs quickly? Use openssl x509 -in <cert.pem> -noout -dates -ext subjectAltName. -dates shows notBefore/notAfter, and the SAN extension lists every hostname the certificate is valid for.