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 RabbitMQ images that run stock Erlang crypto in FIPS mode are limited to TLS 1.2 per erlang.org. 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 a module such as the OpenSSL FIPS provider, not RabbitMQ and not Erlang. Vendors differ on whose module they ship, which certificate it carries, which TLS versions work with it on, and how well the broker, the Erlang runtime and your clients behave when it is on. That is the gap FIPSMQ is built to close: AceMQ delivers it as a complete, supported broker rather than a base image.

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.

Minimus listed a rabbitmq-fips image on the RabbitMQ 4.2 line when we first compared these options. It has since ended operations: its notice says the Minimus registry (reg.mini.dev) was turned off on 22 October 2026 after a 60-day maintenance period, that images pulled before then keep working but receive no further updates, and that key Minimus technology and assets were acquired by Echo. We have taken Minimus out of the comparison (checked 2 November 2026).

If you run a Minimus rabbitmq-fips image today, it no longer receives OpenSSL, Erlang or RabbitMQ patches. Plan the move to a maintained FIPS image or a supported broker, and record the change and its date in your compliance file.

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 a hardened RabbitMQ distribution built on FIPS 140-2 and FIPS 140-3 validated cryptographic modules, and it is delivered, deployed and supported by AceMQ, 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. These are AceMQ's own statements of what FIPSMQ does, from its FIPSMQ page:

• Validated cryptography throughout. Every cryptographic operation, including TLS handshakes, certificate verification and data-in-transit encryption, runs through FIPS 140-2 and FIPS 140-3 validated modules.
• TLS 1.2 and TLS 1.3. Both are enforced with FIPS-approved cipher suites only, with no fallback to non-FIPS algorithms.
• FIPS mode enforced below the application. It runs on an operating system with FIPS mode enabled at the kernel level, plus application-layer enforcement and a hardened TLS configuration.
• Mutual TLS for every client connection, with certificate authorities, lifetimes and cipher suite restrictions configurable per environment.
• Tamper-evident audit logging of authentication events, connection attempts, permission changes and administrative actions, and version-controlled configuration with documented change management.
• Protocols. AMQP 0-9-1, AMQP 1.0, MQTT and STOMP, all secured with FIPS-compliant TLS, plus quorum queues, dead-letter queues, priority queues and the Shovel and Federation plugins.
• High availability. Quorum queues across multiple availability zones with FIPS-approved mTLS between nodes, a 99.99% cluster uptime SLA, failover in under 10 seconds and no message loss on node failure.
• Frameworks. AceMQ states that FIPSMQ satisfies the messaging-layer cryptographic requirements for DoD IL2, IL4 and IL5, FedRAMP Moderate and High, FISMA Moderate and High, FFIEC, HIPAA and CMMC 2.0, out of the box.
• Delivery and support. AceMQ runs a boundary assessment, gap findings and target design, then builds and rolls out in FIPS mode with high availability intact and the configuration evidence your accreditation package needs. 24/7 support carries a 15-minute emergency response, and planned game-day exercises (killing nodes, partitioning networks, exhausting disk) produce a signed report for auditors.

Cryptographic compliance covers the messaging layer, not your whole accreditation, so AceMQ will work through your wider compliance programme with you. For the CMVP certificate and module version that cover your build, ask AceMQ and check the number on csrc.nist.gov as you would for any vendor. 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. RabbitMQ images that run stock Erlang crypto in FIPS mode are limited to TLS 1.2 per erlang.org, and certificates must not rely on md5. FIPSMQ states TLS 1.2 and TLS 1.3, so ask any vendor which versions it supports with FIPS mode on.
5. Ask who supports it when the broker, not the image, misbehaves.

1. Are you a regulated team that wants a supported broker? If you work in federal, defense, financial services or healthcare and want a FIPS RabbitMQ that someone else deploys and answers the pager for, choose FIPSMQ: validated FIPS 140-2 and 140-3 modules, TLS 1.2 and 1.3, and AceMQ 24/7 support in one package.
2. Do you already run RabbitMQ, have a platform team and only need a base image? 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.
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.

We compared four FIPS routes for RabbitMQ, AceMQ FIPSMQ and the Chainguard, Docker Hardened Images and Bitnami Secure Images builds, on eleven criteria that include the cryptographic module and its CMVP certificate, FIPS 140-2 or 140-3, RabbitMQ versions, TLS versions in FIPS mode, frameworks covered, high availability, support model and how you get it. Image certificates were checked on csrc.nist.gov and the vendors' pages on 14 October 2026. Minimus, compared on 20 October 2026, was removed after its registry shut down on 22 October 2026. The FIPSMQ column is AceMQ's own description from its FIPSMQ page, not an independent check. A validated module does not make a deployment compliant, so the page treats the two separately.