Hi Daniil,
Thank you for the thorough architectural breakdown and guidance! Your
suggestion to leverage QpidServiceLoader / PluggableFactoryLoader with a
dedicated module is a much cleaner approach than relying on reflection inside
broker-core.
To address your questions regarding our target environment and scope:
1. Deployment Context & Target Operating Mode
JDK & OS: Java 17 and Java 21 running in containerized RHEL Linux
environments.
BC-FIPS Version & Mode: Bouncy Castle FIPS running strictly in
approved-only mode.
Classpath Constraint: In our targeted deployment runtime, standard bcprov
is completely excluded from the classpath to satisfy strict build and
runtime compliance audits.
2. Required Scope
While self-signed certificate generation is the immediate entry point, our
broader requirements include:
Keystore Support: Loading and handling BCFKS (and modern FIPS-compliant
PKCS12) keystores and truststores.
TLS Connections: Creating SSLContext instances using explicit
BouncyCastleFipsProvider and BCJSSE instances for inbound and outbound AMQP/TLS
transport.
3. Proposed Phased Approach
I agree 100% with splitting this into focused, easily reviewable PRs:
Phase 1 (PR 1: SPI Boundary in broker-core):
Introduce an SPI interface (e.g., SecurityProviderSPI extending Pluggable)
discovered via PluggableFactoryLoader.
Move certificate generation and provider lookup behind this SPI.
Decouple broker-core from direct compile-time org.bouncycastle.* dependencies
and BC-specific exception types.
Provide a standard fallback implementation in broker-core so existing non-FIPS
builds and unit tests remain untouched.
Phase 2 (PR 2: Dedicated FIPS Plugin Module):
Create a separate plugin module (qpid-broker-plugins-security-bcfips) with
compile-time dependencies on bc-fips and bcpkix-fips.
Implement the SPI to handle explicit BouncyCastleFipsProvider instantiation,
BCFKS stores, and BCJSSE integration without mutating the global JVM Security
registry.
If this phased strategy sounds good to you, I will begin by submitting PR 1
focused purely on establishing the SPI boundary in broker-core.
Best regards,
Partha
On 2026/10/09 19:16:18 Daniil Kirilyuk wrote:
> Hi Partha,
>
> Welcome to the Apache Qpid community!
>
> Broker-J’s direct use of Bouncy Castle in the broker runtime is currently
> limited to self-signed certificate generation in
> SSLUtil#generateSelfSignedCertificate(), which is called by
> AutoGeneratedSelfSignedKeyStoreImpl.
>
> Is that the functionality you would like to enhance with FIPS support, or
> do you have broader operations in mind, such as BCFKS / PKCS12-PBMAC1
> keystore support, authentication, configuration encryption, or establishing
> TLS connections through BCJSSE backed by BouncyCastleFipsProvider?
>
> To clarify what "strict FIPS 140 compliance" requires in your deployment,
> it would help to know your target OS / JDK, the intended BC-FIPS version
> and operating mode, and which broker features you need to use. These
> examples are intended to help define the scope; they do not imply that all
> of these areas need to be addressed in this ticket.
>
> If your immediate requirement is limited to self-signed certificate
> generation, a narrow certificate-generation SPI could be a manageable first
> step. Even for that scope, simply replacing the current PROVIDER field
> would not establish that all relevant operations use BC-FIPS: that field is
> used by the certificate converter, while key generation, signing, and
> random-number generation currently rely on default provider selection.
>
> My preference would be to build on the service-loader approach already used
> by Broker-J, with factories discovered through QpidServiceLoader /
> PluggableFactoryLoader and a separate module providing the BC-FIPS
> implementation. That module could have ordinary compile-time dependencies
> on the appropriate BC-FIPS libraries, while broker-core would depend only
> on the SPI. This would avoid the need for reflection to instantiate the
> provider inside SSLUtil.
>
> A startup configuration property could select the implementation. Its
> initialization should happen only after selection, before the operations
> that require it, and startup should fail with a clear explanation if the
> explicitly selected configuration cannot be satisfied. We could agree on
> the exact interface and lifecycle once the required functionality is clear.
>
> I would avoid having that property trigger Security.addProvider() inside
> SSLUtil. Provider registration changes the shared JVM registry, which is
> particularly relevant when Broker-J is embedded or several broker instances
> run in the same JVM. Passing provider instances explicitly would let us
> select providers for the operations covered by the change without modifying
> the host application’s registry.
>
> There is an isolation qualification, however: BC-FIPS also has module-level
> configuration and thread-specific approved-only state. A thread cannot
> leave approved-only mode once it has entered it. Explicit provider
> instances therefore do not, by themselves, guarantee that different
> security policies can coexist within one embedded application.
>
> Factory discovery should also have no security-policy side effects. Our
> service loader instantiates discovered implementations before selecting
> one, so merely adding the FIPS module to the classpath should not activate
> a policy.
>
> The dependency boundary needs attention as well. Core currently depends
> directly on standard BC libraries and exposes BC-specific exception types.
> Moving certificate generation behind an SPI would help remove those
> dependencies from core. We would still need to define compatible dependency
> sets for standard and FIPS deployments: selecting a service through
> configuration does not resolve classpath conflicts, and a separate Maven
> module alone is insufficient.
>
> If the agreed scope requires substantial changes, we may want to split the
> work into several focused PRs to make the changes easier to review and
> track. A narrow first PR could establish the necessary boundary, with
> additional functionality following as separate, clearly scoped changes.
>
> Kind regards,
> Daniil Kirilyuk
>
> On Fri, 9 Oct 2026 at 11:34, Partha Sarathy Maripini via users <
> [email protected]> wrote:
>
> > Hi Qpid Experts,
> >
> > I am working on deploying Apache Qpid Broker-J in regulated environments
> > that mandate strict FIPS 140 compliance. Currently, Broker-J relies on
> > standard Bouncy Castle libraries (bc-prov / bcprov-jdk18on), which are not
> > FIPS 140 certified.
> >
> > I have created a JIRA ticket to track this improvement:
> >
> > *QPID-8773:* https://issues.apache.org/jira/browse/QPID-8773
> >
> > I am preparing a Pull Request for this feature and wanted to gather
> > feedback from the maintainers on the proposed implementation details:
> >
> > 1.
> >
> > *Dynamic Provider Registration:* Introduce a configuration property
> > (e.g., qpid.security.tls.enableFIPSMode=true) to conditionally register
> > org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider inside
> > SSLUtil.java
> > <
> > https://github.com/apache/qpid-broker-j/blob/49098be941a6e6c5c5fc17759c30e0e1e0331c80/broker-core/src/main/java/org/apache/qpid/server/transport/network/security/ssl/SSLUtil.java#L117
> > >
> > and related security modules(if any).
> > 2.
> >
> > *Classpath & Dependency Swap:* Provide a mechanism (e.g., via Maven
> > profiles or provided dependency substitution instructions) to allow
> > deployers to swap bc-prov for bc-fips without classpath conflicts.
> > 3.
> >
> > *Zero Overhead for Standard Users:* Non-FIPS deployments will retain
> > their existing legacy behavior by default.
> >
> > Before finalizing the PR, I would welcome your thoughts on:
> >
> > -
> >
> > Are there any preferred architectural patterns or existing efforts
> > around FIPS compliance in Broker-J?
> > -
> >
> > Is dynamic reflection preferred for registering BouncyCastleFipsProvider
> > to avoid hard compile-time requirements on bc-fips in default builds?
> >
> > Could a committer please assign *QPID-8773* to my JIRA account (*Partha
> > Sarathy Maripini*)?
> >
> > Looking forward to your guidance and contributing this improvement to the
> > project.
> >
> > Best regards,
> >
> > Partha Sarathy Maripini
> >
>
