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 >
