I'm attempting to authenticate with a cloud SQL instance using a client cert:
psql -h "$IP" "sslmode=verify-ca sslkey=certs/tls.key sslcert=certs/tls.crt sslrootcert=certs/ca.crt dbname=postgres"
Password for user root:
The server's cert is in certs/ca.crt
; the client's cert/key in tls.crt
/tls.key
.
As you can see, that appears to be failing, and psql
is apparently falling back to password. How can I either debug this situation, or what is otherwise wrong with the command?
Additionally, when I generate the certificate in GCP, oddly, the only input that is required is a name for the certificate; is this the user? (It seems to end up as the CN
, which is what vanilla PG uses.)
Actually, the following interaction is even more bizarre:
If I do not supply a client certificate, I get told that I need to do that:
# psql -h "$IP" "sslmode=verify-ca sslrootcert=certs/ca.crt dbname=postgres"
psql: error: connection to server at "[…]", port 5432 failed: FATAL: connection requires a valid client certificate
(which is interesting, as we definitely have other stuff merrily working without client certs?)
If I then supply a client cert,
# psql -h "$IP" "sslmode=verify-ca sslrootcert=certs/ca.crt sslkey=certs/tls.key sslcert=certs/tls.crt dbname=postgres"
Password for user root:
psql: error: connection to server at "[…]", port 5432 failed: fe_sendauth: no password supplied
What is going on here? The client cert is valid enough that apparently we no longer get the "connection requires a valid client certificate" error … but yet not valid enough to authenticate? (And we fallback to password, and then ultimately fail?)