Is the connection to hosted postgres TLS 1.2 on public net and TLS 1.3 on private net?
I have a docker image built with my batch code (running deno and pgc4d) and the DO CA cert for a hosted postgres instance.
If I run the docker image (Alpine) locally on my machine (MacOS) using the public connection string, everything works as expected. It can connect to the database, read and write some values and exit normally.
If I deploy the image into a DO hosted Kubernetes cluster using the private connection string, I get an error when it tries to establish a connection to the database.
WARN RS - rustls::session:718 - Sending fatal alert DecodeError error: Uncaught InvalidData: invalid certificate: BadDER at unwrapResponse ($deno$/ops/dispatch_json.ts:43:11) at Object.sendAsync ($deno$/ops/dispatch_json.ts:98:10) at async Object.startTls ($deno$/tls.ts:70:15) at async startTlsPostgres (file:///bin/project/bundle.js:28100:24) at async Object.connectPg (file:///bin/project/bundle.js:28073:28) at async Object.qipMetricsForDay (file:///bin/project/bundle.js:28428:20) at async execute (file:///bin/project/bundle.js:28573:17) at async gExpA (file:///bin/project/bundle.js:79:14) at async file:///bin/project/bundle.js:28601:1
Now this CA cert is bundled in the docker image, so it’s not changing between my running it locally or in the kube cluster. I have code written in node and other languages that connects to DO postgres just fine. It’s just this code using deno.
The section in rustls/session.rs dealing with DecodeError mentions that warnings are nonfatal for TLS1.2, but are outlawed in TLS1.3. Which leads me to believe that my db client code is connecting via TLS1.2 when I run over the public net but connecting via TLS1.3 when using DO’s private net.
Something is not validating correctly with the CA cert. But I don’t know what.
I have other code that does this sort of thing fine, running in docker locally as well as in the kube cluster and talking to DO’s postgres. But the difference here is that this is the first code to use deno, while forcing validation of the pg host certificate using a CA.
Any ideas for tracking this down?