Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
       message can get through to the mailing list cleanly

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux