We are experiencing a Java SSL error while attempting to connect to ClickHouse from Retool self-hosted, using the jdbc Resource type. The error message points to an issue with the trustAnchors parameter being non-empty, which seems to indicate a problem with the Java TrustStore configuration within the Retool environment.
We've confirmed that this issue is unrelated to our Cloud Run or networking configuration.
Error message:
java.sql.SQLException: the trustAnchors parameter must be non-empty, server ClickHouseNode
...
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty at java.base/java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:200)
Is there an environment variable missing or some configuration we can add to resolve this issue?
It seems there could be a couple reasons, how do you have your self deployed instance set up? Are you using docker compose, values.yaml or Helm charts?
It seems there could be a couple reasons, how do you have your self deployed instance set up?
We run the application using Cloud Run in GCP (Google Cloud Platform). It's using the tryretool/backend:3.52.1-stable backend image, which we pull from dockerhub.
"GCP Cloud Run is a fully managed service that allows you to run containerized applications in a scalable and serverless environment."
Are you using docker compose, values.yaml or Helm charts?
From the ClickHouse docs it looks like there are several options.
The bug is likely coming from how you set up the Java driver for this resource. Make sure that you read the ClickHouse docs to make sure that the versions match up with the Java version being used in tryretool/backend:3.52.1-stable backend image.
Also on a side note, Cloud Run is not a supported deployment method as it only allows for a single container. Making it difficult if not impossible to scale up your Retool instance to handle volume of traffic.
We’re currently using com.clickhouse.jdbc.ClickHouseDriver. This is the approach recommended by the ClickHouse Docs. It has worked well in our Retool-hosted setup, but since transitioning to a self-hosted environment, we’ve encountered an issue where it only works when sslmode=none is set in the connection string, which we’d prefer to avoid.
Also on a side note, Cloud Run is not a supported deployment method as it only allows for a single container. Making it difficult if not impossible to scale up your Retool instance to handle volume of traffic.
We’ve been running Retool on Cloud Run, and the api deployment has been successfully scaling up to multiple instances without any problems.
That last response helped me narrow down the problem greatly! Now that I know SSL mode is able to control the bug, I know this is not a versioning issues with Java.
Very interesting that the issue did not occur on cloud but did occur when migrating to self hosted Just want to double check that the Java driver is the same version on cloud as the one being used by the resource on self hosted.
I believe the issue is that our resource would need to pass in the SSL cert, I found an older internal thread asking about this from 2023 where our core data team said we did not have the functionality for passing the SSL cert.
Which is that the Java driver is looking for when it throws that error.
Waiting to hear back from our core data team on if this has been fixed or if it is on the roadmap to be fixed/added. If it is not, I will definitely make a feature request to get this on our radar!
Very interesting that the issue did not occur on cloud but did occur when migrating to self hosted Just want to double check that the Java driver is the same version on cloud as the one being used by the resource on self hosted.
I don't believe I can configure the Java driver version from Retool resource UI.
I have a lead on how we can set this up, we believe that you need to add ca certs to your pod. The ca certs could then point to a pem file via theNODE_EXTRA_CA_CERTS env var in your dockerfile.
Currently waiting on our infra team to confirm the diagnosis and see if they have any set up examples as you would need to add this to all of one’s backend/dbc pods!
Will let you know any more details as they come in
Just heard back. They told me that you would need to mount the cert bundle to the docker container, which should be possible in all Docker-based environments but how to do so will differ by provider.
Part of the issue is that we do not have any docs on how to add certs or point to certs on Google Cloud Run as it is not currently a supported deployment method.
We have lots of reference material for k8s and helm but basically none for gcr.
In a k8s deployment setup, it would just be a volume + volumeMount + env var
You would have to translate the file mount part to however gcr makes users do such.
My best advice would be to look into how gcr handles certs, volumes and env vars, this unfortunately falls outside of the scope of the Retool teams knowledge.
Apologies for the inconvenience, it should definitely be possible to get the cert for the trustAnchor set to handle SSL, but their docs/support team would be best for helping with this!
Just want to double check that the Java driver is the same version on cloud as the one being used by the resource on self hosted.
as it is not currently a supported deployment method.