SSL connection does not work properly

[parsiazare]

I've been trying to get this to work with SSL and am running into this error from the docker logs:
LOG: could not accept SSL connection: sslv3 alert bad certificate

Here is my connection string that does not work:
mermerd -c postgresql://david:password@localhost:5433/david?sslmode=verify-full&sslcert=$PWD/packages/david-db/src/client.crt&sslkey=$PWD/packages/david-db/src/client.key&sslrootcert=$PWD/packages/david-db/src/ca.crt -s public --useAllTables -o docs/erd.mmd

Using the same certificates with docker works fine:
docker exec -i david-test psql -U david -d david sslmode=verify-full sslrootcert=$PWD/packages/david-db/src/ca.crt sslkey=$PWD/packages/david-db/src/client.key sslcert=$PWD/packages/david-db/src/client.crt

The certificates also work correctly with pgAdmin and knex migrations.

[sachasmart-weavik]

I think this could be an issue with environment variables. Currently, I'm trying to implement a solution and package this in a Dockerfile and pass in the .env variables. The connection string does not take .env as far as I can see... Your $PWD is therefore going to go in a $PWD

[KarnerTh]

@parsiazare I see some open issues regarding sslmode in the used pgx package - I will look into it

[sachasmart-weavik]

I created a fork (I guess 21 days ago) where you can pass in a 'environment' parameter in the config.yaml. I initialized viper.AutomaticEnv() in root.go, but only call the .environment variables if the condition is met in the config.go ConnectionString(). Have to say, I know next to nothing about Go lol so its very hacky.

Regardless, super cool app that we are/will be running some actions through with our commits.

Thanks!

[KarnerTh]

It is possible to expand env variables in the connection string (spf13/viper#119 (comment))

I could already confirm that it works and I added an integration test to test the ssl connection parameters.
I will finish up the changes and release a new version (probably today).

@sachasmart-weavik does this also include/fix your use case or do you need the possibility to split up the connection parameters into different variables like in your fork?

[sachasmart-weavik]

Ooh that looks promising, yes that should work... My preference would be not to split up the variables into different parameters, instead something like would be better postgres://${USER}:${PASSWORD}@${HOST}:${PORT}/${DB}.

[KarnerTh]

Expanding env variables is now available in version 0.4.0

@sachasmart-weavik The example from your last comment should work now - please let me know if does not :)

[perigrin]

I work with @parsiazare … and this is awesome response, thank you!