Ecto SSL verification with Google SQL - 'connection requires a valid client certificate'

In a similar security posture, post a credit card number here to get faster debugging help

The symptoms you’re describing make me wonder if Erlang has the right certs in its trust root.

I can drop a Monero wallet address if that counts

Hm, maybe you’re right

Screenshot 2022-08-02 at 20.30.16509×485 22.7 KB

I’ve assumed that self-signed certificate should be handled by cacertfile option.

I have the same issue attempting to run verification: verify_peer and cacert file with cockroachdb’s cacert. Have yet to determine actual solution. I suspect we share the same problem and are looking for the same solution.

There is some benefit to using TLS even with verify: :verify_none: a passive attacker who can only monitor, but not modify, network traffic will not be able to decode the traffic exchanged with the server.

Verification of the server certificate is necessary to protect against an active attacker. In a closed network environment like GCP some might argue that the risk of an active attacker is somewhat reduced, compared to connections that traverse the public internet.

If the server has a self-signed certificate, the certificate itself can’t be used to establish trust, in the same way that a CA-issued certificate can. But as long as the server continues to present the same certificate, or use the same key pair, you can ‘pin’ the certificate/public key and abort the connection if a different cert/key is used (which then requires manual verification to see if the change is legit or someone is trying to interfere).

The ssl_verify_fun package README has instructions on how to enable certificate or public key pinning. In Elixir that would look something like:

:ssl.connect('self-signed.badssl.com', 443,
  verify_fun: {&:ssl_verify_fingerprint.verify_fun/3, [check_fingerprint: {:sha, "36F81BA2C9B18032D8B7BC61B26F22F6086DAA95"}]},
  verify: :verify_none,
  reuse_sessions: false
)

(It doesn’t really matter here whether you pass verify: :verify_none or verify: :verify_peer - the verify_fun option overrides the default behaviors selected by that option anyway, but in recent OTP versions you’ll get a warning if you don’t set :verify option at all)

(Also note that you probably wouldn’t want to use reuse_sessions: false in production, but it is necessary while testing otherwise a full handshake may not be performed and your changes to the connection options won’t take effect, leading to surprising results)

Thank @voltone . I’ll try this. Great blog you got.

I’ve been able to fix this error, occurring when attempting to connect to a Google Cloud SQL instance by restricting the versions options in ssl_opts to [:"tlsv1.2"].
While debugging I noticed an initial handshake attempt over TLS v1.3, then downgrading to a handshake over TLS v1.2 and then an error being returned. After restricting to TLS v1.2 only, the initial handshake attempt is successful and a connection is established afterwards.
NB: Google Cloud SQL supports only TLS versions 1.0, 1.1 and 1.2.

Amazing, thanks for the shout out.

Are you using verify: :verify_peer with that?

Hitting the same problem with Amazon RDS. Will try your fix too.

Nope, I was able to make it work with verify: :verify_none, and :keyfile, cacertfile, certfile properly set.

Are you on an OTP version less than 25?

In my libs (using the advice from @voltone) I’m configuring TLS 1.2 and 1.3 on OTP 25 and only 1.2 on earlier OTP versions. That seems to have stabilised this particular issue (not just on GCP, also on Github actions)