Stream: ibm
Topic: change Keystore passwords
Cornelius Erbelding (Dec 14 2020 at 08:36):
Hi everyone,
i'm facing the following problem with my dockerized IBM FHIR Server:
Changing the password of fhirKeyStore.p12 works well, as this keystore is mounted from the host machine (containing the local https-certificate).
When changing the password of fhirTrustStore.p12 in server.xml (as this is the only place where i can find the password-configuration) accessing the keystore fails.
Is it really necessary to mount a fhirTrustStore.p12 with the updated password or is there another password-configuration anywhere?
Paul Bastide (Dec 15 2020 at 17:00):
Hi Cornelius, one option you can mount a configDrops/override that has the updated details, it might not do exactly what you want, however, it should override the server.xml behavior for the keystore
Paul Bastide (Dec 15 2020 at 17:00):
Otherwise, I don't think you can as part of the image update the fhirtTrustStore.p12 password in the image itself
Paul Bastide (Dec 15 2020 at 17:33):
Thinking about this some more - maybe we could make an enhancement to externalize it? @Lee Surprenant when you get a second what do you think?
Lee Surprenant (Dec 15 2020 at 18:17):
Is it really necessary to mount a fhirTrustStore.p12 with the updated password or is there another password-configuration anywhere?
the configured trustStore password (in server.xml or a configDropin) really does need to match the actual password of the configured truststore.
this truststore is used for two main things:
- designating which client certs the server should trust (we enable mutual TLS by default, but with these sample certs)
- security the connection of outbound TLS (although the db connection may use a different one...i know postgresql does)
are you using mTLS?
if not, you can decide how tight to make your truststore. one thing I'd like to do is update the server to use the default java truststore by default (e.g. by setting the following env property which is supported by liberty:
SEC_TLS_TRUSTDEFAULTCERTS=true). the only thing stopping me is that currently we ship with that sample mTLS setup and so we still need our self-signed client cert in the truststore for that to work.
Lee Surprenant (Dec 15 2020 at 18:17):
maybe we could make an enhancement to externalize it?
sounds reasonable to me. is there a keytool command for changing the password of an existing store? or do you need to create a new one and copy over the entries?
Cornelius Erbelding (Dec 16 2020 at 06:15):
sounds reasonable to me. is there a keytool command for changing the password of an existing store? or do you need to create a new one and copy over the entries?
Yes, there is one: keytool -storepasswd -keystore fhirTrustStore.p12
Cornelius Erbelding (Dec 16 2020 at 06:16):
one option you can mount a configDrops/override that has the updated details, it might not do exactly what you want, however, it should override the server.xml behavior for the keystore
Otherwise, I don't think you can as part of the image update the fhirtTrustStore.p12 password in the image itself
I've copied the fhirTrustStore.p12 from the Docker-Container, changed the password and mounted it directly to ./resources/security/fhirTrustStore.p12.
My keystore credentials (for fhirTrustStore and fhirKeyStore) are passed as environment variables, therefore, the server.xml contains the ${variable} part.
However, it does work for the fhirKeyStore containing my local SSL certificate, but not for the fhirTrustStore.
The Error is keytool error: java.io.FileNotFoundException: resources/security/fhirTrustStore.p12 (Permission denied) (when trying to import Keycloaks realm- & instance-certificate)
Direct access to the keystore (via docker exec -it CONTAINER /bin/bash & keytool --list -v -keystore fhirTrustStore.p12) works with the same password.
When accessing the running FHIR-Server, the JWT-Tokens can't be validated as the Token-Signer can't be found within the fhirTrustStore.p12
Last updated: Apr 12 2022 at 19:14 UTC
