Skip to content

Conversation

@hhund
Copy link
Member

@hhund hhund commented Aug 27, 2025

Default trusted CAs are now stored as separate files.

  • Default trusted CAs (root, issuing or chains - root and issuing) are now stored as separate files in folders of the bpe, bpe_proxy, fhir and fhir_proxy docker images.
  • The config parameters of the fhir and bpe servers can be configured with a folder containing (*.pem, *.crt) files or a single file with multiple pem encoded CAs. By default a folder is configured, allowing additions or full override via docker bind mount, but a single custom file can still be configured.
  • The fhir_proxy and bpe_proxy images have now default folders configured via the SSL_CA_DN_REQUEST_PATH and SSL_CA_CERTIFICATE_PATH environment variables. The matching ..._PATH variables are ignored if SSL_CA_DN_REQUEST_FILE or SSL_CA_CERTIFICATE_FILE point to existing files. This change also enables addition or replacement via docker bind
    mount and configuration of single files via the ...FILE variables.
  • The symlinks with sha1 hashes of a canonicalized form of the subject DN string needed for apache httpd are created during container startup.
  • Improved logging of trusted CAs.
  • Adds new FhirClientConfigProvider to the API with access to client configs (moved from FhirClientProvider), the default client config trust store and a method to create an SSLContext based on the default trust store.
  • Cleanup of some javac warnings.

closes #204
closes #207

hhund added 2 commits August 27, 2025 18:05
Default trusted CAs (root, issuing or chains - root and issuing) are now
stored as separate files in folders of the bpe, bpe_proxy, fhir and
fhir_proxy docker images.
The config parameters of the fhir and bpe servers can be configured with
a folder containing (*.pem, *.crt) files or a single file with multiple
pem encoded CAs. By default a folder is configured, allowing additions
or full override via docker bind mount, but a single custom file can
still be configured.
The fhir_proxy and bpe_proxy images have now default folders configured
via the SSL_CA_DN_REQUEST_PATH and SSL_CA_CERTIFICATE_PATH environment
variables. The matching ..._PATH variables are ignored if
SSL_CA_DN_REQUEST_FILE or SSL_CA_CERTIFICATE_FILE point to existing
files. This change also enablsd addition or replacement via docker bind
mount and configuration of single files via the ...FILE variables.
The symlinks with sha1 hashes of a canonicalized form of the subject DN
string needed for apache httpd are created during container startup.
BPE should not crash if a process plugins has a miss configured
ProcessPluginDefinition that breaks the jvm service loader, but specific
plugin should be ignored.
@hhund hhund added this to the 2.0.0 milestone Aug 27, 2025
@hhund hhund requested review from schwzr and wetret August 27, 2025 16:11
@hhund hhund self-assigned this Aug 27, 2025
@hhund hhund changed the title Issue/204 207 trusted c as Issue/204 207 trusted cas Aug 27, 2025
Adds new FhirClientConfigProvider to the API with access to client
configs (moved from FhirClientProvider), the default client config trust
store and a method to create a SSLContext based on the default trust
store.
New integration test for config provider.
* disabled annotation processor from log4j2-core by disabling all
annotations processors in modules with a log42-core dependency
* mockito-core configured as java agent for tests in modules where
needed
* added missing deprecation annotations
* fixed bad method signatures in classes implementing HAPIs
IValidationSupport interface
* removed not needed method with potentially unsafe var-arg
* configured maven-resources-plugin propertyEncoding and fixed
BuildInfoReaderImpl to use UTF-8
Copy link
Collaborator

@jaboehri jaboehri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a question concerning the changes in AbstractCertificateConfig#createKeyStore: why is the first cert expected to be a client cert?

@hhund
Copy link
Member Author

hhund commented Sep 5, 2025

I have a question concerning the changes in AbstractCertificateConfig#createKeyStore: why is the first cert expected to be a client cert?

The private AbstractCertificateConfig.createKeyStore(char[], String, String, Path, Path, List<X509Certificate>, PrivateKey) method is only called by the protected methods AbstractCertificateConfig.createClientKeyStore(String, String, char[], char[], String, String) and AbstractCertificateConfig.createOptionalClientKeyStore(String, String, char[], char[], String, String).

Nevertheless renamed to createClientKeyStore via 95b95e3

@hhund hhund merged commit 73c9979 into develop_2 Sep 5, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add Service to Access Trusted Certificate Authorities via Plugin API Add Default Trusted Certificate Authorities to Docker Images

4 participants