I am trying to connect to a Postgres instance running on Google Cloud Platform using psql.
I got the certificate using:
gcloud beta sql ssl server-ca-certs list --instance=[instance-name] --format='value(cert)' > server-ca.pem
and then tried connecting using psql to the instance using:
psql "host=[ip] port=[port] user=[user] dbname=[db] sslmode=verify-ca sslrootcert=server-ca.pem"
This returns the error: SSL error: invalid padding
I have checked the certificate for valid unix endlines, changed the wrapping (making sure the whole certificate fits on one line, etc.)
Any pointers into what might be going wrong here or how to debug this are very welcome!
Creating a new server-ca certificate and rotating it solved the SSL connection issue.
Related
When trying to get a psql shell (not using iam user) I am receiving:
> gcloud alpha sql connect pg-instance --database mydb --user myuser --project my-project
Starting Cloud SQL Proxy: [/Users/me/google-cloud-sdk/bin/cloud_sql_proxy -instances my-project:us-central1:pg-instance=tcp:9470 -credential_file /Users/me/.config/gcloud/legacy_credentials/me#me.com/adc.json]]
2022/03/15 14:47:59 Rlimits for file descriptors set to {Current = 8500, Max = 9223372036854775807}
2022/03/15 14:47:59 using credential file for authentication; path="/Users/me/.config/gcloud/legacy_credentials/me#me.com/adc.json"
2022/03/15 14:48:00 Listening on 127.0.0.1:9470 for my-project:us-central1:pg-instance
2022/03/15 14:48:00 Ready for new connections
Connecting to database with SQL user [myuser].Password:
psql: error: connection to server at "127.0.0.1", port 9470 failed: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
I had the same error message when connecting to Postgres(Cloud Sql) using a service account.
In my setup I did run cloud_sql_proxy inside docker container.
In order to make it work I had to add extra configuration defined in step #9 https://cloud.google.com/sql/docs/sqlserver/connect-docker#connect-client
docker run -d \
-v <PATH_TO_KEY_FILE>:/config \
-p 127.0.0.1:5432:5432\
gcr.io/cloudsql-docker/gce-proxy:1.33.1 /cloud_sql_proxy \
-instances=<INSTANCE_CONNECTION_NAME>=tcp:0.0.0.0:5432 -credential_file=/config
The missing bits were: host ip on port mapping and 0.0.0.0: in cloud_sql_proxy command
There are a few things I would like to point out. The best starting point for me would be the About connection options page; both the Overview and the Before you begin sections are very helpful to get the full idea of the process and how to properly configure the user. But the most important part is the Connection Options, for the message connection to server at "127.0.0.1" I’m guessing it is a private IP, but please make sure this section is covered before starting to debug.
In your case, the logs are saying there was an error in the connection to the server…
I used the Troubleshoot guide that includes the Diagnose issues link to get to the Debug connection issues page that has a lot of useful information on how to debug any connectivity issue.
Generally, connection issues fall into one of the following three areas:
Connecting - are you able to reach your instance over the network?
Authorizing - are you authorized to connect to the instance?
Authenticating - does the database accept your database credentials?
Each of those can be further broken down into different paths for investigation.
Once determining the connection method, there are different questions that will help to guide you through the possible troubleshooting paths.
If using these guides doesn’t get you a solution, please make sure to update your answer with the results, steps, and information followed to provide further help. This would be a good example, as it has the same log error, and this other question shows that there are a few different troubleshooting paths for this specific log message, plus they have useful information for you.
I have a MariaDB server set up with self-signed certificates to connect using TLS. This works when I connect with the corresponding client
$ mysql -u xxxx -h xx.xx.xx.xx -p
\s shows:
mysql Ver 15.1 Distrib 10.1.37-MariaDB, for debian-linux-gnu (x86_64)
SSL: Cipher in use is DHE-RSA-AES256-SHA
The .my.cnf contains:
$ cat ~/.my.cnf
[client]
ssl-cert=/---path-deleted---/client-cert.pem
ssl-key=/---path-deleted---/client-key.pem
Problem: I don't manage to connect from a Perl script with these settings. Without SSL, the script works. As soon as I enable SSL in the script (and enforce it on the server), I get:
failed: SSL connection error: ASN: bad other signature confirmation
When I check the certificates with openssl, I get
$ openssl verify ca-cert.pem client-cert.pem server-cert.pem
error 18 at 0 depth lookup: self signed certificate
The certificates are indeed self-signed, and I want to keep it that way.
If I use "mariadb_ssl_verify_server_cert=0", I get
failed: SSL connection error: Enforcing SSL encryption is not supported without mariadb_ssl_verify_server_cert=1
What do I need to change to have a TLS-connection working from Perl?
I copy the lines of code I have in my connect sub for reference. A very similar code used to work on an older system with mysql (not mariadb), using just mysql_ssl=1 IIRC:
$self->{dsn} = "DBI:MariaDB:database=$database;host=$db_host;mariadb_ssl=1;".
"mariadb_ssl_verify_server_cert=1;".
"mariadb_ssl_ca_file=/---path---/ca-key.pem;".
"mariadb_ssl_client_key=/---path---/client-key.pem;".
"mariadb_ssl_client_cert=/---path---/client-cert.pem";
$self->{dbh} = DBI->connect($self->{dsn}, $db_user, $db_passwd,
{'RaiseError' => 1, 'PrintError' => 1, AutoCommit => 1});
I had a similar problem, albeit using DBI:mysql.
Issue was that I specified the IP address in the connection string rather than the servername, as specified in the SSL certificate CN. The mysql command line client didn't mind, but DBI:mysql does.
To get the CN of the certificate, I used openssl as per https://serverfault.com/a/931652/243186
I then needed to add an entry in my /etc/hosts file such that the CN matched the IP of the interface I was connecting to.
An alternate solution would have been for the MySQL server owner to have generated an SSL SAN cert specifying all possible servernames and IPs it could be connected to as.
I am trying to configure keycloak to run with PostgreSQL (using Azure Database for PostgreSQL) using a docker container. I was able to do this as instructed in the keycloak documentation here.
The problem that I am facing is, Azure Database for PostgreSQL has this option "Enforce SSL connection" set to "Enable" by default and the keycloak server is not working with that. It throws following error at the server startup.
ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 49) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./auth:
Caused by: org.postgresql.util.PSQLException: FATAL: SSL connection is required. Please specify SSL options and retry.
If the option "Enforce SSL connection" is disabled it worked fine.
I would like to know how to specify this option to work with keycloak.
I am using a custom Dockerfile to download and boot keycloak server and passing the data-source parameters as environmental variables with the docker run command. I have tried this approach which worked fine when I point it to my PostgreSQL data-source without any modifications. But when I change it to be compatible with my own Dockerfile it gives the same error.
Thanks in advance.
so here's what I did.
I overlooked the latest Dockerfile shared by jboss (which is available here) and adopted the lines that I needed with the version of my requirement. Earlier I was trying to add postgreSQL configuration by my own as keycloak document was suggesting. Since it is now supported out of the box I changed my Dockerfile to be compatible with jboss Dockerfile for keycloak.
Also I introduced new env. variable to enforce SSL connection by stating ssl=true as guided here
FATAL: SSL connection is required. Please specify SSL options and retry.
I've seen this happen when the client IP address isn't included in the firewall rules on the PostgreSQL server. Try confirming the firewall is open for your IP in the Connection Security page in the portal or in the Azure CLI using az postgres server firewall-rule list --resource-group --server-name
When I try to create a connection using SQL Developer 4.0.2 on MAC OS I got the following error message :
The Network Adapter could not establish the connection’ (ORA-17002) error.
ORA-17002 is a generic error code shown when the client cannot connect to the database. The actual fix can be found only if we have additional info.
You can start by troubleshooting the following.
1. Check if the database server can be pinged.
2. check if the port is accessible by running telnet.
3. check if there are any firewall rules blocking access to database.
run the below command in mac cli:
sudo scutil --set HostName localhost
I would like to connect to my Postgres 8.3 database using SSL from my XP client using OpenSSL. This works fine without SSL. When I try it with SSL (no client certificate), I get the error:
error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure
I suspect that I need to change something with the Postgres configuration but I don't know what. I have followed the instructions in the Postgres manual for SSL including creating a self-signed certificate. In my pg_hba.conf there is a line:
host dbname loginname 123.45.67.89/32 md5
Is there something else I should be looking at?
This is an error inside OpenSSL. It doesn't sound like a PostgreSQL configuration problem. However, it could be an OpenSSL config problem - check if you have any non-detailt openssl.conf on the machine(s).
Also, what version of OpenSSL do you have on the server, and what OS is that? If you have a really old one, that could be the reason.