Enhance Docker Image Support for Non-Public/Untrusted CA Certificates

[siarhei-fedziukovich]

Name and Version

0.6.0

What is the problem this feature will solve?

Currently, our Admin Back services are implemented in Java, and the existing Docker images works seamlessly with public/trusted Certificate Authorities (CAs), issues arise when certificates signed by non-public/untrusted CAs need to be added. In such cases, manual intervention is required to modify the logic of the entrypoint

The root of the problem lies in the fact that our base images (eclipse-temurin:21-jdk-alpine, eclipse-temurin:17-jre-noble) already include an autogenerated helper script (__cacert_entrypoint.sh) for adding certificates signed by non-public/untrusted CAs. This script leverages the environment variable USE_SYSTEM_CA_CERTS to control its behavior and expects certificates to be mounted in the /certificates/ directory. However, since the ENTRYPOINT instruction of the base images directly calls the __cacert_entrypoint.sh script, it overrides the logic of our custom docker entrypoint. As a result, the ability to seamlessly work with non-public/untrusted CA certificates without manual intervention is lost.

What is the feature you are proposing to solve the problem?

To address this issue, we propose modifying the existing docker entrypoint to incorporate the execution of the __cacert_entrypoint.sh script when the USE_SYSTEM_CA_CERTS environment variable is set. This change will enable the automatic handling of non-public/untrusted CA certificates without requiring additional manual adjustments to the script logic.

Specifically, the proposed changes include:

1. Adding a conditional check in docker-entrypoint.sh to detect the presence of the USE_SYSTEM_CA_CERTS environment variable.
2. If the variable is set, execute the __cacert_entrypoint.sh script to handle certificates mounted in the /certificates/ directory.
3. Ensure backward compatibility and maintain the existing functionality for public/trusted CA certificates.
   By implementing this enhancement, we can reduce the maintenance overhead for deploying solutions in closed environments (e.g., customer-specific perimeters) and streamline the process of working with non-public/untrusted CA certificates.

What alternatives have you considered?

No response