FIPS-Compliant RabbitMQ Options Compared

RabbitMQ has no FIPS documentation page: rabbitmq.com/docs/fips returns a 404 as of 14 October 2026. FIPS is not an open-source RabbitMQ feature, it is a property of how a vendor builds the stack underneath it. The Erlang crypto FIPS documentation sets the rules: Erlang needs a FIPS-enabled OpenSSL, the fips_mode setting must be true before the crypto module loads (it cannot be toggled on a running node), non-validated algorithms such as md5 are disabled, and the page says you are limited to TLS 1.2 in FIPS mode. The RabbitMQ Erlang version guide notes that Erlang 26.1 and later support FIPS mode on OpenSSL 3.

The consequence for any comparison: the cryptographic module being validated is the OpenSSL FIPS provider, not RabbitMQ and not Erlang. Vendors differ on whose provider build they ship, which certificate it carries, and how well the broker, the Erlang runtime and your clients behave when it is on.

Chainguard publishes a rabbitmq-fips image. Chainguard's FIPS images use its OpenSSL FIPS provider. NIST certificate #5102 is Chainguard's provider certificate: FIPS 140-3, Active, validated 4 December 2025, sunset 10 March 2030, overall level 1. The image page does not state which certificate the rabbitmq-fips image carries, so ask Chainguard for the attestation of the exact tag you plan to run.

The image's own page is clear that FIPS mode is not automatic: you point RABBITMQ_ADVANCED_CONFIG_FILE at the supplied sys.config that sets fips_mode to true, then confirm it with rabbitmqctl environment. It suits teams that already operate RabbitMQ and want a minimal, hardened base image. What you buy is the image and its patching, not a RabbitMQ engineer on the pager. FIPS images are on a paid plan, quoted per image or per catalogue.

The Docker Hardened Images RabbitMQ catalogue lists FIPS tags for the 4.3 line (4.3-fips, 4.3.6-fips and 4-fips, each with a -fips-dev variant) on Debian 13. Docker's FIPS documentation says the FIPS variant needs a paid subscription and that the image attests the modules it contains. Its worked example shows the OpenSSL FIPS Provider under certificate #4985: FIPS 140-3, Active, initial validation 11 March 2025 with an update on 21 November 2025, sunset 10 March 2030. That example is not specific to RabbitMQ, so read the attestation of the RabbitMQ image you pull.

Docker is also direct about the limit: a FIPS variant helps meet compliance requirements but does not make an application or system fully compliant. The catalogue only offers the 4.3 line for RabbitMQ. When we checked, it showed "Support ending Jul 2026" with an extended-support request link, so confirm the current support window with Docker against your upgrade plan.

Bitnami Secure Images, now part of Broadcom's Tanzu portfolio, has a FIPS 140-2 and 140-3 document for the catalogue. For OpenSSL it cites two NIST entries: #5147, VMware's OpenSSL FIPS Provider, FIPS 140-3, Active, validated 27 January 2026, sunset 10 March 2030; and #4861, the FIPS 140-2 predecessor, which NIST has moved to Historical because of sunsetting. NIST advises federal agencies not to include a Historical module in new procurements, so the 140-3 certificate is the one to ask about.

The document says Photon-based images run OpenSSL in FIPS mode by default and warns that some bundled applications may not be inherently FIPS compliant. We could not verify a RabbitMQ-specific FIPS image, its tags or its versions on that page, so treat Bitnami as the option to confirm with the vendor before you plan around it.

FIPSMQ is AceMQ's FIPS-compliant message broker. It is built on RabbitMQ, lists the AMQP 0-9-1 and AMQP 1.0 protocols, and is delivered with AceMQ 24/7 support, so the people who deploy it are the people who answer when it breaks. It is the only option here that is a supported broker rather than an image.

This page does not publish the cryptographic module name, certificate number, RabbitMQ versions or FIPS 140 level for FIPSMQ; those are on request, and you should ask for them in the same form we ask the image vendors above: a CMVP number you can open on csrc.nist.gov and check is Active. Audit evidence for RabbitMQ estates, such as supported versions and patch records, is covered on the RabbitMQ compliance page.

A FIPS-validated module and a FIPS-compliant RabbitMQ are different claims. Validation applies to a specific cryptographic module, tested in a defined configuration, and it is listed on NIST's Cryptographic Module Validation Program. Compliance describes a whole system: the module, the Erlang runtime that calls it, the operating system, your certificates and your clients. A hardened image gives you the first and helps with the second; it cannot promise the third. Use this checklist with any vendor, including us:

1. Get the CMVP number for the module in the exact image or build, and the module version.
2. Open the NIST page and confirm the certificate is Active, the standard (140-2 or 140-3) and the sunset date. A Historical certificate should not be in a new procurement.
3. Confirm FIPS mode is on in the running broker, not only present in the image.
4. Test TLS end to end with your real clients. In Erlang FIPS mode the documentation limits you to TLS 1.2, and certificates must not rely on md5.
5. Ask who supports it when the broker, not the image, misbehaves.

1. Do you already run RabbitMQ and have a platform team? If yes, an image from Chainguard or Docker Hardened Images fits, and you keep the pager. Pick the vendor that already supplies your other images.
2. Do you want a supported FIPS broker and not just an image? If yes, FIPSMQ with AceMQ 24/7 support is the option built for that.
3. Are you a Bitnami Secure Images customer? Ask Broadcom for a RabbitMQ FIPS attestation before you rely on it.
4. Whichever you choose, write the certificate number, its Active status and the date you checked it into your compliance record.