Add CA certificate path customization for HTTPS connections

[mozeks]

This commit introduces the ability to customize the CA certificate path used by the UID2Client when establishing HTTPS connections. It enables setting the certificate file and directory path through the environment variables CA_CERT_FILE_PATH and CA_CERT_DIR_PATH, respectively. If these variables are not set, the client defaults to using standard paths for CA certificates.

Background:
While using uid2-client lib with OpenSSL 1.1.1k, Refresh was failing with "Failed to refresh keys: error code: 10, verify error: unable to get local issuer certificate" error. Same issue was observed when executing openssl s_client -connect global.prod.uidapi.com:443 -showcerts, indicating a problem with locating or validating the CA certificate. However, when specifying the certificate path directly using the -CApath or -CAfile option in OpenSSL, the verification succeeded. This behavior highlighted the need for a way to specify the CA certificate path in the UID2Client.

Key Changes:

• Added checks to set the CA certificate file and directory paths based on the environment variables CA_CERT_FILE_PATH and CA_CERT_DIR_PATH.
• Set the default CA certificate file path to "/etc/ssl/certs/ca-certificates.crt" and the directory path to "/etc/ssl/certs/" if the environment variables are not set.

By allowing the CA certificate paths to be customized, this change addresses the verification issue encountered with OpenSSL 1.1.1k, providing flexibility and configurability for environments with custom CA certificates or when running in containers or non-standard environments.

[mozeks]

While the current implementation leverages environment variables (CA_CERT_FILE_PATH and CA_CERT_DIR_PATH) to set the CA certificate paths, we could consider enhancing the UID2Client interface by introducing a set_ca_cert_path function. This function would allow users to programmatically specify the certificate paths directly in their application code, offering a more dynamic and explicit approach compared to environment variables.

[jon8787]

Thanks for your contribution! Your suggestion to introduce a set_ca_cert_path function sounds good. This has the advantage of not defaulting to OS-specific defaults and also doesn't require using non-standard environment variables.

Before going down that path, we'd like to understand whether this could be solved at another layer, such that openssl s_client -connect global.prod.uidapi.com:443 -showcerts works without having to specify the certificate path. Eg could it be fixed by ensuring OPENSSLDIR/certs links to the correct path, per https://stackoverflow.com/questions/36449336/what-is-my-openssl-and-ssl-default-ca-certs-path ?

[mozeks]

Thank you for the feedback! I conducted the openssl s_client -connect global.prod.uidapi.com:443 -showcerts command inside a Docker environment where OpenSSL 1.1.1k is installed and encountered the certificate error. It's noteworthy that in our production environment, which uses OpenSSL 1.1.0l by default, this command executes successfully without any certificate issues.

However, our application employs OpenSSL 1.1.1k via the gRPC library, where the concept of OPENSSLDIR isn't directly applicable or inherited in the same way as it would be in a typical OpenSSL installation environment. This discrepancy between the OpenSSL versions and their associated environments underlines the challenge we're addressing.

Given this context, while adjusting the OPENSSLDIR could potentially resolve the issue in a standard environment, the dynamic nature of our application's usage of OpenSSL varying environments—necessitates a more adaptable solution, like the proposed set_ca_cert_path function, to ensure robust and flexible certificate verification across different deployment scenarios.

[jon8787]

Thanks for the additional information. Is there any way you can provide a repro, eg via a Dockerfile?