Repository navigation
Import all PEM certificates with BCFIPS - #53613
Conversation
c707e2a to
038076b
Compare
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The focused implementation addresses the provider-specific stream behavior and includes appropriate regression coverage.
Review effort: Balanced
Findings: None
What changed in this PR
Fixes multi-certificate PEM imports when using BCFIPS.
Changes:
- Wraps PEM file streams in
BufferedInputStream. - Adds an approved-only BCFIPS regression test importing two certificates.
| File | Description |
|---|---|
services/src/main/java/org/keycloak/truststore/TruststoreBuilder.java |
Enables BCFIPS to process each PEM certificate. |
crypto/fips1402/src/test/java/org/keycloak/crypto/fips/test/FIPS1402KeystoreTypesTest.java |
Verifies both certificates reach a BCFKS truststore. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Hey @shawkins 👋🏻 Could I kindly ask you to have a look at this one? |
|
I detected this independently and created a draft PR in #53706. WDYT about using |
|
Thanks for checking this one @rmartinc! We highly appreciate your time!
I'm not sure this is necessary. A while back I've implemented using BCFKS for Strict FIPS mode (see #50149). Using PKCS12 for non-strict should probably be allowed as it's not strictly forbidden by the FIPS spec. In order to guarantee that nothing slips in in FIPS mode, my change uses BCFKS. With the above in mind, I think we should never end up in this codepath when FIPS Strict mode is enabled (unless I missed something). |
|
@slaskawi My change was only to use X.509 implementation in the BC (not the java one). But whatever you prefer, and what about using |
@rmartinc I've been experimenting on the side with alternative Crypto Providers (GlaSSLess in #51082 and Project Brisbane in #53711). This is being coordinated with @stianst and we're looking at how complicated it is to support FIPS without Bouncy Castle. If any of this experiments take off, we might be interested in lowering Keycloak dependency on Bouncy Castle. But to be fair - we're quite far away from that point. With the above in mind, my personal preference (but feel free to ignore me) is to limit code dependencies to BC if possible. I think in this particular piece of code, we might get away with just sticking to the Java implementation. But let me also ask you - what benefits does it bring if we switched to
Switching to |
I agree. |
|
@Josh-Tracy Then just change to use |
rmartinc
left a comment
There was a problem hiding this comment.
Thanks @Josh-Tracy! LGTM! Just please add the signature to the second commit (git commit --amend --signoff) to pass the DCO check. Later we can run the CI with this.
slaskawi
left a comment
There was a problem hiding this comment.
Looks good from my side as well!
2a0dd96 to
2087b30
Compare
Signed :) |
rmartinc
left a comment
There was a problem hiding this comment.
Thanks @Josh-Tracy! Approved! I have started the CI.
@shawkins Do you want to also take a look?
shawkins
left a comment
There was a problem hiding this comment.
LGTM, thanks @Josh-Tracy and @rmartinc
|
@Josh-Tracy I'm going to rebase, the CI issue is because #53856. So it should be fixed with the rebase. |
Closes keycloak#53612 Signed-off-by: josh-tracy <josh.tracy@defenseunicorns.com>
Signed-off-by: josh-tracy <josh.tracy@defenseunicorns.com>
2087b30 to
e903054
Compare
* Import all PEM certificates with BCFIPS Closes keycloak#53612 Signed-off-by: josh-tracy <josh.tracy@defenseunicorns.com> * Import all certificates from PEM bundles Signed-off-by: josh-tracy <josh.tracy@defenseunicorns.com> --------- Signed-off-by: josh-tracy <josh.tracy@defenseunicorns.com>
* Import all PEM certificates with BCFIPS Closes keycloak#53612 Signed-off-by: josh-tracy <josh.tracy@defenseunicorns.com> * Import all certificates from PEM bundles Signed-off-by: josh-tracy <josh.tracy@defenseunicorns.com> --------- Signed-off-by: josh-tracy <josh.tracy@defenseunicorns.com>
Closes #53612
Summary
With BCFIPS,
CertificateFactory.generateCertificate()can consume an entire multi-certificate PEM file when given a non-markableFileInputStream.TruststoreBuilderthen imports only the first certificate without reporting an error.This change wraps the input in
BufferedInputStream, allowing the existing import loop to read each certificate. It also adds a regression test that loads two distinct certificates from one PEM file and verifies both appear in the generated BCFKS truststore in BCFIPS approved-only mode.Testing
TruststoreBuilderTest: 12 passed on JDK 21.FIPS1402KeystoreTypesTest: new regression test ran and passed with BCFIPS approved-only mode on JDK 21; two tests for non-approved mode were skipped as expected.spotless:checkpassed.The BCFIPS test ran on Ubuntu with FIPS settings for the test JVM, not on an OS-level FIPS-certified host. End-to-end client-certificate authentication was not tested.
Deployment validation
We also tested the change in a controlled comparison on a running deployment using a downstream Keycloak 26.7.3-based FIPS container image on kubernetes running in HA mode. Both replicas used the same mounted multi-certificate PEM bundle and BCFIPS provider; only one replica had the buffered-stream change documented here.
A provider-level probe imported 1 of 177 certificate blocks with
FileInputStreamand all 177 withBufferedInputStream. The original replica's generated BCFKS truststore omitted 29 distinct certificates from the bundle; the patched replica omitted none and retained all entries present in the original truststore. Both replicas became Ready.Documentation
No documentation change: this fixes certificate import for the existing
--truststore-pathsbehavior.AI assistance
An AI coding agent assisted with the implementation and regression test. I reviewed the change and am responsible for addressing review feedback.