Custom CA shell scripts

[svethitov]

🚀 Pull Request Checklist

• Title: Custom CA Shell scripts

• Description:
  Add a couple of shell scripts that allow the FDP Schema Update Tool to be executed against an endpoint served with a Custom CA Certificate.

• Context: Some FDP endpoints might be served with custom Certificate Authorities. This allows for flexible addition of trusted Root certificates at runtime without rebuilding the docker image.

• Changes:

  • Added: A couple of shell scripts. The first allows for the creation of a custom trust store. The second allows for the usage of the trust store.

• Testing:

  • The shell scripts have been used to apply the schema definitions to two instances (dev and staging) at the Bulgarian GDI node.

• Screenshots (if applicable):

  • NA

• Additional Information:

  • NA

• Checklist:

  • I have checked that my code adheres to the project's style guidelines and that my code is well-commented.
  • I have performed self-review of my own code and corrected any misspellings.
  • I have made corresponding changes to the documentation (if applicable).
  • My changes generate no new warnings or errors.
  • I have added tests that prove my fix is effective or that my feature works.
  • New and existing unit tests pass locally with my changes.

[hcvdwerf]

I have a question about this
If the FDP is publicly exposed and uses a certificate issued by a publicly trusted CA (e.g., Let’s Encrypt, DigiCert, GlobalSign), the default JVM truststore should already validate the TLS chain correctly. In that scenario, introducing a custom truststore does not improve security but does introduce additional operational complexity:

• Extra scripts and maintenance burden
• Volume mounts and JVM configuration flags
• Additional failure modes (PKIX issues, mismatches, etc.)

[svethitov]

@hcvdwerf, I agree with you that it adds operational complexity. The use case for this is if the FDP endpoint is not publicly available. For example, at our node we have two instances of the GDI FDP, at the moment. Development and Staging environment. We have no plans for exposing the dev environment, not even to the rest of the GDI network. It is just for internal testing. When it is just internal there is no point using publicly trusted CA.

As I mentioned during one of the WP4 meetings, we do have our reservations about exposing publicly the FDP and the AF Beacon for the moment. We were actually planning to expose only the internal proxy to the GDI portal and the Beacon Network.

Furthermore, when working internally, for example applying changes with the schema tool, we are doing this directly through internal clients.

[hcvdwerf]

Could you add license information in the top?

for example

#!/usr/bin/env bash

SPDX-FileCopyrightText: Stichting Health-RI

SPDX-License-Identifier: AGPL-3.0-only

[hcvdwerf]

also here ;-)

[svethitov]

@hcvdwerf I've added SPDX field but honestly I might have done it wrong. Who should be the copyright owner. Is it the individual country nodes or is it the 1PLUSMG initiative (I do not thing we have a legal entity yet).

[hcvdwerf]

Please resolve comments