psql: SSL error: certificate verify failed - heroku

I'm encountering a frustrating problem connecting to Heroku Postgres using psql and in psycopg2, on sslmode=require.
When connecting with the next examples on debian (python 2.7.13) I'm encountering the same problem of
psql: SSL error: certificate verify failed
psql:
psql "host=<MyHost> sslmode=require" --port=5432 --username=<MyUser> --password
Psycopg2:
import psycopg2
db_url = "postgres://User:Pwd#Host:5432/DB?sslmode=require"
psycopg2.connect(db_url)
I tried to change the postgresql.conf and pg_hba.conf as described here:
PSQL: SSL error: unknown protocol
No Luck.
My versions:
psycopg2=-2.6.2
OpenSSL=1.1.0j 20 Nov 2018
postgres=9.6

Ok. I figured out that in my system, somehow there is a root.crt file in the ~/postgresql dir. The .crt file made the whole problem (it wasn't certificated to Heroku) and when I deleted it, the connection worked.
FYI

Related

Self signed certificate in certificate chain issue using Azure CLI on Windows

I have some trouble configuring my Windows to work with az command line tools. I have tested multiple configuration. One on locally installed system and one with windows based docker container. I get the same error on both system.
In case I issue the following command:
az login --tenant my-domain.org
I get the following error:
HTTPSConnectionPool(host='login.microsoftonline.com', port=443): Max retries exceeded with url: /my-domain.org/.well-known/openid-configuration (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain (_ssl.c:1125)')))
The container has the following az and openssl version:
PS C:\azp> az version
{
"azure-cli": "2.28.0",
"azure-cli-core": "2.28.0",
"azure-cli-telemetry": "1.0.6",
"extensions": {}
}
PS C:\azp> openssl version
OpenSSL 1.1.1k 25 Mar 2021
The local system has the following az and openssl version:
(base) PS C:\01_Dev\dockerdevimage> az version
{
"azure-cli": "2.26.1",
"azure-cli-core": "2.26.1",
"azure-cli-telemetry": "1.0.6",
"extensions": {}
}
(base) PS C:\01_Dev\dockerdevimage> openssl version
OpenSSL 1.1.1c 28 May 2019
I tried to understand why I get the error, so I tested the connection with openssl as follows:
PS C:\azp> openssl s_client -proxy 10.76.209.147:3128 -connect login.microsoftonline.com:443 -showcerts
CONNECTED(00000180)
Can't use SSL_get_servername
depth=2 DC = org, DC = my-domain, CN = PKI, CN = BB-CA-DD <-- edited manually
verify error:num=19:self signed certificate in certificate chain
verify return:1
I have also tested with the same proxy server and with Linux container and the az command works as expected:
$ az version
{
"azure-cli": "2.25.0",
"azure-cli-core": "2.25.0",
"azure-cli-telemetry": "1.0.6",
"extensions": {}
}
$ openssl version
OpenSSL 1.1.1f 31 Mar 2020
$ az login --tenant my-domain.org
The default web browser has been opened at https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/oauth2/authorize. Please continue the login in the web browser. If no web browser is available or if the web browser fails to open, use device code flow with `az login --use-device-code`.
You have logged in. Now let us find all the subscriptions to which you have access...
[
{
"cloudName": "AzureCloud",
...
On Linux container the openssl command returns the following output:
$ openssl s_client -proxy 10.76.209.147:3128 -connect login.microsoftonline.com:443 -showcerts
Can't use SSL_get_servername
depth=2 DC = org, DC = my-domain, CN = PKI, CN = BB-CA-DD
verify return:1
I have also imported the certificate with the following command based on this link:
PS C:\azp> Import-Certificate -FilePath .\BB-CA-DD.crt -CertStoreLocation Cert:\LocalMachine\Root\
No changes. I'm not sure how to proceed.
Maybe this issue is related to the following posts and articles:
Can OpenSSL on Windows use the system certificate store?
How to Use OpenSSL with a Windows Certificate Authority to Generate TLS Certificates
Installing TLS / SSL ROOT Certificates to non-standard environments
Edit:
I've moved the solution from here to an Answer block to highlight that the issue for me was resolved. Based on the reactions, I've concluded that it is indeed useful for others too.
Finally I was able to resolve the issue as follows:
I've found the following documentation:
Setting up certificates for Azure CLI on Azure Stack Development Kit
The basic idea is to find the python installation used for Azure CLI and update the related certificate file.
In my case the Azure CLI was installed with python on the following location:
C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe
And using the command, that was suggested, returned as follows:
PS > & "C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe" -c "import certifi; print(certifi.where())"
C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\lib\site-packages\certifi\cacert.pem
Updating the file mentioned above solved the az login issue for me. One of the python installation provided by my-domain.org contained a properly configured cacert.pem file.
You can use following method
Your azure CLI is looking for the cert at this location (if using Windows)
Default certificate authority bundle
Windows C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\Lib\site-packages\certifi\cacert.pem
Download the Certificate of your Azure Portal (portal.azure.com)
Append the certificate on above cacert.pem file
and try Az login again After restarting powershell.
Alternatively
If you're using Azure CLI over a proxy server, it may cause the following error: SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",). To address this error, set the environment variable REQUESTS_CA_BUNDLE to the path of certificate authority bundle certificate file in PEM format.
Append the proxy server's certificate to this file or copy the contents to another certificate file, then set REQUESTS_CA_BUNDLE to it. You might also need to set the HTTP_PROXY or HTTPS_PROXY environment variables.
Link to Ms Docs Solution
I solved this problem by changing DNS for IPv4. Maybe it can work for you too. I ran az upgrade command after DNS change. When I ran az upgrade while giving this error, it said "check internet connection". It was upgraded with success and the related error has been resolved.
I used Google DNS as DNS.
8.8.8.8
8.8.4.4
Then I set DNS to automatic option. I can continue to use it without any problems. I can now access with the az login command.

psql: error: could not connect to server: FATAL: password authentication failed for user

I have successfully installed postgresql and added path to my environment variable in windows 10. But the problem is when i try to run psql postgresql in command prompt it gives error saying
C:\Users\adity>psql postgres
Password for user adity:
psql: error: could not connect to server: FATAL: password authentication failed for user "adity"
I am 100% sure my password is correct I have tried reinstalling and uninstalling many time in case i missed password but every time it gives me same error. Although when i try to run from GUI it starts running. This is frustrating and I am not sure what the problem is.
The database superuser that was created during database cluster creation is very likely called postgres.
So rather than using the default, which is to use the database user whose name is the same as your current operating system user, explicitly specify the database user postgres:
psql -U postgres

Trouble Connecting to RDS PostgresQL SSL in Laravel

I'm trying to setup my Laravel app in Docker to connect to a Postgresql database hosted on AWS RDS using SSL. In my config, I have the address of the certificate:
'sslmode' => env('DB_SSLMODE', 'verify-full'),
'sslrootcert' => env('DB_SSLROOTCERT', '/usr/local/share/ca-certificates/rds-combined-ca-bundle.pem')
I don't have anything overriding this in my .env file. I am able to connect to the server using psql:
psql -h {address} -p 5432 "dbname={dbname} user={user} sslrootcert=/usr/local/share/ca-certificates/rds-combined-ca-bundle-root.pem sslmode=verify-full"
So I believe that I have the key setup properly. I get this error from Laravel:
SQLSTATE[08006] [7] root certificate file "/usr/local/share/ca-certificates/rds-combined-ca-bundle.pem" does not exist Either provide the file or change sslmode to disable server certificate verification
And you better believe that file exists. Anyone have any ideas of things that I can try?
Thanks!
Scott
Turns out I had AWS set to accept both the 2015 and 2019 keys, and I just needed it to accept the 2019 key.

psql: could not connect to server: No such file or directory on Windows

When I try to connect to my postgresql database with psql I receive the error message:
D:\>psql -U postgres
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5112"?
A similar error I get when using createdb:
createdb: could not connect to database template1: could not connect to server: No such file or directory
next two lines are identical to the psql error.
I can start pgadminIII without problems and access my databases. when I check the properties of the connection it uses port 5432. When using process explorer I see about 5 postgresql processes, though none accessing port 5432. The solutions I found in this forum are about linux/osx platforms, which I am not able to translate into a windows solution.
Could anybody tell what is wrong/what I am doing wrong and suggest a solution?
Thanks for your time.

Connect to Postgres on Mac osX

Part of an install includes a postgres database install. The database is running and the App that uses it is connecting fine.
I want to use the postgres install for some of my own reporting needs. I've got a fair way to getting to the database but I am stumped at the last bit.
I can do a psql -h /path/to/socket but get
psql: FATAL: authentication failed for user "postgres": invalid authentication method.
I have gone in to the pg_hba.conf and the only lines not commented are:
local all all trust
host all all 127.0.0.1/32 trust
host all all ::1/128 trust
As far as I can see this should mean any local attempt at connection would be trusted and therefore OK.
I've tried with specifying different users (root, me, etc) and always get the same reply. Any ideas how I can access the server?

Resources