Обсуждение: [ODBC] Connection string parameter sslrootcert does not work
Hi,
I'm trying to programmatically connect to an RDS Postgres instance with SSL enabled, using the psqlodbc driver (Version: postgresql94-odbc-09.03.0400-1PGDG.rhel6.x86_64.rpm). I’m having trouble with the sslrootcert parameter.
To enable SSL for a Postgres connection, I appended the following parameters to the connection string:
sslmode=verify-ca;sslrootcert=<location of root certificate on the client>
The root certificate exists as a .pem file.
In addition, I also enabled the debug and comm logs:
debug=1;commlog=1
The resulting logs showed the following error:
…
00028427: 2017-01-17T21:16:57 [SERVER ]I: Going to connect to ODBC connection string: Driver={PostgreSQL Unicode(x64)};Server=<hostname>;Port=-<port>;Database=<database-name>;UseDeclareFetch=1;Fetch=10000;Uid=<username>;Pwd=****;sslmode=verify-ca;sslrootcert=<location of root.pem file on the client>;debug=1;commlog=1
00028427: 2017-01-17T21:16:57 [SERVER ]E: RetCode: SQL_ERROR SqlState: 08001 NativeError: 101 Message: [unixODBC]root certificate file "/home/<current-user>/.postgresql/root.crt" does not exist
Either provide the file or change sslmode to disable server certificate verification. [122502] ODBC general error.
00028427: 2017-01-17T21:16:57 [SERVER ]E: Failed to connect [122506] Network error has occurred
…
I’ve also attached the contents of the mylog and psqlodbc.log files. Note that the log files have been sanitized to remove any sensitive information.
Does this mean the driver cannot recognize the sslrootcert parameter being passed to it? Why does it still refer to the default location of the root certificate? I even tried putting the root certificate in the default location, but it still failed with the same error above.
I was looking up this issue and found a similar thread that was open 3 years ago: https://www.postgresql.org/message-id/5462D5AA.2040602%40tpf.co.jp
The contributor there had mentioned that there was no option to specify path name. Is that still the case? Or has that been corrected? If not, is there a plan to fix it?
Thanks,
Apurva