search

highmed / highmed-dsf

HiGHmed Data Sharing Framework funded by the German Federal Ministry of Education and Research (BMBF, grant ids: 01ZZ1802E and 01ZZ1802A)
Apache License 2.0
32 stars 20 forks source link

Old certificate thumbprint still persisted after renewal #361

Closed bauerjs1 closed 2 years ago

bauerjs1 commented 2 years ago

Hi there,

thanks for updating my certificate SHA in the GTH-allow-list! After exchanging the client certificate locally, I still got some warnings about an unknown thumbprint (the old one). Just to note, I am not sure how much of an issue this is, because I was struggling with different things at the same time.

Since I did not have the old thumbprint left in any configuration parameters/files, I believe it was still persisted somewhere in the database. A complete teardown of the (test 😉) environment, including the DB volume, and re-install with the same configuration solved it for now.

I guess, some deletion feature in the DB is missing here. Or does the thumbprint need to be persisted in the DB anyway, if it is specified in the ENVs?

Cheers, Johannes

hhund commented 2 years ago

Hi Johannes,

the thumbprint of your organizations main client-certificate, meaning the client-certificate that your organization uses via the DSF to authenticate against DSF FHIR servers from other organizations e.g. the GECCO Transfer Hub, needs to be part of the Organization FHIR resource for your organization not only as part of the "allow-list" at other organization but also as part of your own allow-list. Since the environment variable ORG_HIGHMED_DSF_FHIR_SERVER_USER_THUMBPRINTS can be used to privately define additional thumbprints, you could configure a bad thumbprint as part of your allow-list and still be able to access your own DSF FHIR server.

Within the default NUM-CODEX configuration for non HiGHmed organizations, the Organization resource for your own organization is supplied to your local database via the /opt/fhir/conf/bundle.xml file on startup of the DSF FHIR server. The entries of that transaction bundle are configured as conditional updates, meaning that the will perform an update on the database on every restart. Within that file the thumbprint is inserted via property substitution and the substituted value needs to be configured via the environment variable ORG_HIGHMED_DSF_FHIR_SERVER_ORGANIZATION_THUMBPRINT.
In case you have to change your client certificate the variable needs to change as well, which of course means that the docker container needs to be re-created (down / up).

Let me know if this explains the existence of the old thumbprint. I'd guess you did not re-created the container after modifying the environment variables.

bauerjs1 commented 2 years ago

Hi Hauke,

I can confirm the container was re-created after updating the certificate files and thumbprint (docker-compose up does that automatically when it detects changes in the service configurations).

We are using the default non-HiGHmed CODEX configuration which populates the ENVs into the bundle.

hhund commented 2 years ago

I just double checked if I could modify the thumbprint within the Organization resource of the database via a container re-create and it worked.

Please let me know If you can reproduce the problem, otherwise I would opt to close this issue.

bauerjs1 commented 2 years ago

Okay I could reproduce the issue but found the issue somewhere else. Since DSF-FHIR and BPE are deployed independently, certificates aren't updated at the exact same time – the warnings are produced as long as they have different certs configured, because the DSF-FHIR doesn't know the BPE's thumbprint in this case.

So this totally makes sense, I just didn't notice that the warnings were dropped during this exact time window.

Thanks and cheers!