Re: PQConnectdb SSL (sslmode): Is this a bug

On Mon, Aug 29, 2005 at 04:23:13PM -0700, vishal saberwal wrote:
> now i ran the program i had that has a conect command with ("hostaddr=
> 169.254.59.60 <http://169.254.59.60> dbname=dbm user=postgres
> sslmode=prefer") parameters.
>
> [root(at)localhost serv]# ./bin/test_lib
> Connection failed: could not open certificate file
> "/root/.postgresql/postgresql.crt": No such file or directory
> ret=-1
>
> I don't think i need to have ~/.postgresql/postgresql.crt on server. I
> thought that was the requirement only with the clients ... so, i think i
> shouldn't be getting this error. On server (as per documentation) i need to
> have the files in $PGDATA rather than in ~/.postgresql. Hence this question.

An application that connects to the database is a client, regardless
of what machine it runs on. If the client (the application) makes
a TCP connection to the server (the database) and the server requests
a certificate, then the client must provide a certificate or the
server will reject the connection. To learn more about what files
go where and how they're used, see "Secure TCP/IP Connections with
SSL" and "SSL Support" in the documentation:

http://www.postgresql.org/docs/8.0/static/ssl-tcp.html
http://www.postgresql.org/docs/8.0/static/libpq-ssl.html

> (a) Where am i going wrong?

You're trying to do client authentication with a version of libpq
that won't work, and when you do link with a good version of libpq
then you're not providing a client certificate.

> (b) Why are the error messages different?

Because the failure modes are different. In one case the client
is apparently attempting to make an SSL connection without a
certificate; in the other case the client is looking for a certificate
and can't find one.

> (c) When LD_LIBRARY_PATH is set to /usr/local/pgsql/lib, then why does it
> matter if the links on /usr/lib/libpq.so are changed?

That's a system issue, not a PostgreSQL issue. Some people consider
LD_LIBRARY_PATH to be an ugly hack anyway and recommend against its
use except for testing purposes. You might want to consider using
linker options that tell the executable where to find its shared
libraries at run time; see your build tools' documentation for details.

--
Michael Fuhr